home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 4_1_01.tro < prev    next >
Text File  |  1991-12-13  |  105KB  |  3,799 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright ( c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v | 5i'
  22. .sp 1P
  23. .ce 1000
  24. \v'14P'
  25. \s12FASCICLE\ IV.1
  26. \v'4P'
  27. .RT
  28. .ce 0
  29. .sp 1P
  30. .ce 1000
  31. \fBRecommendations\ M.10\ to\ M.782\fR \v'2P'
  32. .EF '%     \ \ \ ^''
  33. .OF ''' \ \ \ ^    %'
  34. .ce 0
  35. .sp 1P
  36. .ce 1000
  37. \fBGENERAL\ MAINTENANCE\ PRINCIPLES\fR 
  38. .ce 0
  39. .ce 1000
  40. \fBMAINTENANCE\ OF\ INTERNATIONAL\ TRANSMISSION\fR 
  41. .ce 0
  42. .sp 1P
  43. .ce 1000
  44. \fBSYSTEMS\ AND\ TELEPHONE\ CIRCUITS\fR \v'2P'
  45. .ce 0
  46. .sp 1P
  47. .LP
  48. .rs
  49. .sp 22P
  50. .ad r
  51. Blanc
  52. .ad b
  53. .RT
  54. .LP
  55. .bp
  56. .LP
  57. \fBMONTAGE:\fR \ PAGE 2 = PAGE BLANCHE
  58. .sp 1P
  59. .RT
  60. .LP
  61. .EF '%    Fascicle\ IV.1\ \(em\ Rec.\ M.10''
  62. .OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.10    %'
  63. .LP
  64. .bp
  65. .sp 1P
  66. .ce 1000
  67. \v'3P'
  68. \fBINTRODUCTION\fR 
  69. .ce 0
  70. .sp 1P
  71. .sp 2P
  72. .LP
  73. \fBRecommendation\ M.10\fR 
  74. .RT
  75. .sp 2P
  76. .sp 1P
  77. .ce 1000
  78. \fBGENERAL\ RECOMMENDATION\ CONCERNING\ MAINTENANCE\fR 
  79. .EF '%    Fascicle\ IV.1\ \(em\ Rec.\ M.10''
  80. .OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.10    %'
  81. .ce 0
  82. .sp 1P
  83. .PP
  84. To enable Administrations to cooperate effectively in
  85. maintaining the characteristics required for the international
  86. telecommunication services, the relevant CCITT\ Recommendations, which 
  87. are based on long experience, should be applied. 
  88. \v'2P'
  89. .sp 1P
  90. .RT
  91. .sp 2P
  92. .LP
  93. \fBRecommendation\ M.15\fR 
  94. .RT
  95. .sp 2P
  96. .sp 1P
  97. .ce 1000
  98. \fBMAINTENANCE\ CONSIDERATIONS\ FOR\ NEW\ SYSTEMS\fR 
  99. .EF '%    Fascicle\ IV.1\ \(em\ Rec.\ M.15''
  100. .OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.15    %'
  101. .ce 0
  102. .sp 1P
  103. .LP
  104. \fB1\fR     \fBGeneral\fR 
  105. .sp 1P
  106. .RT
  107. .PP
  108. To ensure that new systems are implemented so as to permit
  109. compatible international operation and maintenance in the most effective
  110. manner, the following guiding principles are indicated.
  111. .RT
  112. .sp 2P
  113. .LP
  114. \fB2\fR     \fBPrinciples\fR 
  115. .sp 1P
  116. .RT
  117. .PP
  118. 2.1
  119. When a new system is being studied, early consideration should be given 
  120. to operational and maintenance requirements. 
  121. .sp 9p
  122. .RT
  123. .PP
  124. 2.2
  125. The maintenance organization and maintenance facilities (including test 
  126. equipment) should be considered early enough to ensure their availability 
  127. when the new system is introduced. 
  128. .PP
  129. 2.3
  130. In order to reduce total (lifetime) costs and to improve the
  131. efficiency of maintenance, new systems should be provided with internal
  132. supervision and fault localization functions. Such functions reduce the 
  133. number and type of external test equipment to a minimum, and make it possible 
  134. to omit most external routine tests. 
  135. .PP
  136. 2.4
  137. Where existing maintenance procedures, for example fault
  138. reporting, are not appropriate, alternative procedures should be considered
  139. early enough to ensure their application when the new system is introduced.
  140. However, any new procedures should consider established maintenance principles 
  141. accepted by the CCITT. 
  142. .LP
  143. .rs
  144. .sp 7P
  145. .ad r
  146. Blanc
  147. .ad b
  148. .RT
  149. .LP
  150. .bp
  151. .sp 2P
  152. .LP
  153. \fBRecommendation\ M.20\fR 
  154. .RT
  155. .sp 2P
  156. .sp 1P
  157. .ce 1000
  158. \fBMAINTENANCE\ PHILOSOPHY\ FOR\ TELECOMMUNICATIONS\ NETWORKS\fR 
  159. .EF '%    Fascicle\ IV.1\ \(em\ Rec.\ M.20''
  160. .OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.20    %'
  161. .ce 0
  162. .sp 1P
  163. .ce 1000
  164. (The principles described in Recommendation M.21 should also be taken into
  165. account.)
  166. .sp 9p
  167. .RT
  168. .ce 0
  169. .sp 1P
  170. .LP
  171. \fB1\fR     \fBGeneral\fR 
  172. .sp 1P
  173. .RT
  174. .PP
  175. 1.1
  176. Maintenance involves the whole of operations required for
  177. setting up and maintaining, within prescribed limits, any element entering
  178. into the setting\(hyup of a connection (see Recommendation\ M.60)
  179. .FS
  180. It is
  181. recognized that for some Administrations, bringing into service is not
  182. considered to be part of maintenance.
  183. .FE
  184. . In order to properly plan and
  185. program the maintenance operations required to establish and maintain an
  186. analogue, digital or mixed network, the following general strategy is
  187. recommended.
  188. .sp 9p
  189. .RT
  190. .PP
  191. 1.1.1
  192. A maintenance organization should be established using the guiding principles 
  193. set forth in Recommendations\ M.70 and M.710 for automatic circuits switched 
  194. over analogue, digital and mixed networks. In addition, the concept of 
  195. control and subcontrol stations found in Recommendations\ M.80 and\ M.90 
  196. for 
  197. international circuits and transmission systems should be implemented.
  198. .PP
  199. 1.1.2
  200. The strategy should include the following maintenance operations considerations: 
  201. .LP
  202.     a)
  203.     It should consider the evolution of the network from the
  204. present highly analogue environment to the future almost wholly
  205. digital environment. In doing this, it must consider the new
  206. services and functions offered by the networks (e.g.\ CCITT
  207. Signalling System No.\ 7 and ISDN) and the maintenance tools and
  208. capabilities becoming available (e.g.\ performance monitoring).
  209. .LP
  210.     b)
  211.     It should employ an overall maintenance philosophy that uses
  212. the maintenance entity concept, failure classification and
  213. network supervision process specified in \(sc\ 3.
  214. .LP
  215.     c)
  216.     It should provide for the maintenance of the network
  217. systems, equipment and circuits during the following
  218. activities:
  219. .LP
  220.     \(em
  221.     installation and acceptance testing (\(sc\ 4);
  222. .LP
  223.     \(em
  224.     bringing into service (\(sc 4);
  225. .LP
  226.     \(em
  227.     keeping the network operational (\(sc 5).
  228. .LP
  229.     It should support other maintenance activities (\(sc 6)
  230. associated with the administration of maintenance operations
  231. (e.g., data bases, spare parts, failure statistics,\ etc.) along
  232. with a detailed plan for preventive maintenance, where required,
  233. on the various telecommunication equipments.
  234. .LP
  235.     d)
  236.     It should have as a major aim to minimize both the
  237. occurrence and the impact of failures and to ensure that in
  238. cause of failure:
  239. .LP
  240.     \(em
  241.     the right personnel can be sent to
  242. .LP
  243.     \(em
  244.     the right place with
  245. .LP
  246.     \(em
  247.     the right equipment
  248. .LP
  249.     \(em
  250.     the right information at
  251. .LP
  252.     \(em
  253.     the right time to perform
  254. .LP
  255.     \(em
  256.     the right actions.
  257. .PP
  258. 1.2
  259. To apply this general strategy in a network, the following
  260. principles can be used:
  261. .sp 9p
  262. .RT
  263. .LP
  264.     \fIPreventive maintenance\fR 
  265. .LP
  266.     The maintenance carried out at predetermined intervals or
  267. according to prescribed criteria and intended to reduce the
  268. probability of failure or the degradation of the functioning of an
  269. item.
  270. .LP
  271. .sp 1
  272. .bp
  273. .LP
  274.     \fICorrective maintenance\fR 
  275. .LP
  276.      The maintenance carried out after fault recognition and intended to restore 
  277. an item to a state in which it can perform a required 
  278. function.
  279. .LP
  280.     \fIControlled maintenance\fR 
  281. .LP
  282.      A method to sustain a desired quality of service by the systematic application 
  283. of analysis techniques using centralized supervisory 
  284. facilities and/or sampling to minimize preventive maintenance and to
  285. reduce corrective maintenance.
  286. .PP
  287. 1.3
  288. In general for all three types of network (analogue, digital
  289. and mixed), the use of controlled maintenance principles is recommended,
  290. i.e.,\ the maintenance actions are determined on the basis of information
  291. generated in the maintained system or coming from auxiliary supervision
  292. systems.
  293. .sp 9p
  294. .RT
  295. .PP
  296. 1.4
  297. The advantages of the controlled maintenance approach are that
  298. it directs future maintenance activity to those areas where a known improvement 
  299. in service to the customer will be achieved. The monitoring techniques 
  300. which 
  301. are inherent in controlled maintenance provide data which simplify the
  302. identification of hidden faults by using statistical analysis.
  303. .PP
  304. 1.5
  305. The smaller the portion of the network which is affected by a
  306. failure, the more difficult and/or less economic it may be to detect it
  307. using controlled maintenance techniques. In these cases corrective and/or
  308. preventive maintenance techniques may have to be employed.
  309. .PP
  310. 1.6
  311. In analogue and mixed networks a mixture of the
  312. above\(hymentioned principles are used, depending on the existing equipment
  313. included in the network (see Recommendations\ M.710, M.715 to M.725).
  314. .PP
  315. 1.7
  316. The maintenance philosophy and fundamental principles are
  317. closely linked to:
  318. .LP
  319.     \(em
  320.     availability performance;
  321. .LP
  322.     \(em
  323.     network technical performance;
  324. .LP
  325.     \(em
  326.     network economics.
  327. .sp 2P
  328. .LP
  329. \fB2\fR     \fBMaintenance objectives\fR 
  330. .sp 1P
  331. .RT
  332. .sp 1P
  333. .LP
  334. 2.1
  335.     \fIPurpose\fR 
  336. .sp 9p
  337. .RT
  338. .PP
  339. The main purpose of a general maintenance philosophy for analogue, digital 
  340. and mixed networks is to accomplish the aims defined in \(sc\ 1.1. 
  341. .PP
  342. In addition the following objectives should be fulfilled:
  343. .RT
  344. .LP
  345.     \(em
  346.      For a defined level of service the total cost should be kept to a minimum 
  347. by the use of appropriate methods (e.g.\ centralized 
  348. operation and maintenance).
  349. .LP
  350.     \(em
  351.     The same maintenance philosophy should be applied to
  352. exchanges, transmission equipment, data equipment, subscriber
  353. terminals, etc., wherever possible.
  354. .sp 1P
  355. .LP
  356. 2.2
  357.     \fIEconomics\fR 
  358. .sp 9p
  359. .RT
  360. .PP
  361. New technology provides new possibilities for low cost maintenance not 
  362. only for individual exchanges, but for the whole network, e.g.\ using the 
  363. same technology for both transmission and switching.
  364. .PP
  365. The operation and maintenance functions in a network should be planned 
  366. in such a way that the life cost will be a minimum. For a defined level 
  367. of 
  368. service the total cost consists of:
  369. .RT
  370. .LP
  371.     \(em
  372.     investment cost
  373. .LP
  374.     \(em
  375.     operations cost
  376. .LP
  377.     \(em
  378.     maintenance cost
  379. .LP
  380.     \(em
  381.     cost for loss of traffic.
  382. .sp 1P
  383. .LP
  384. 2.3
  385.     \fITransition from analogue to digital networks\fR 
  386. .sp 9p
  387. .RT
  388. .PP
  389. The basic philosophy, as described in this Recommendation, is valid in 
  390. principle, for analogue, mixed and digital networks. However, many 
  391. digital network parts are more suited to the implementation
  392. of controlled maintenance than are analogue network parts. Due to new
  393. technological developments maintenance functions can be incorporated within 
  394. the digital equipment. Analogue equipment often requires additional external 
  395. maintenance systems in order to permit controlled maintenance, e.g.\ ATME\ 
  396. No.\ 2 (Recommendation\ O.22\ [1]). 
  397. .bp
  398. .RT
  399. .sp 1P
  400. .LP
  401. 2.4
  402.     \fICentralized maintenance operations\fR 
  403. .sp 9p
  404. .RT
  405. .PP
  406. The introduction of digital telecommunications equipment with
  407. enhanced maintenance operations functions, including the facility for remote
  408. reporting and control, provides new opportunities for centralization.
  409. Supplement No.\ 6.2\ [2] provides a description of a centralized maintenance
  410. organization. There are many benefits that can be gained from centralization. 
  411. These include the ability to: 
  412. .RT
  413. .LP
  414.     \(em
  415.     be more flexible in the organization of maintenance
  416. operations and administration;
  417. .LP
  418.     \(em
  419.     utilize highly skilled mechanical resources more
  420. efficiently;
  421. .LP
  422.     \(em
  423.     utilize more effectively data and data bases;
  424. .LP
  425.     \(em
  426.     improve maintenance effectiveness;
  427. .LP
  428.     \(em
  429.     decrease maintenance costs;
  430. .LP
  431.     \(em
  432.     increase the availability of transmission and
  433. switching systems;
  434. .LP
  435.     \(em
  436.     improve quality of service.
  437. .PP
  438. \fINote\fR \ \(em\ By the use of remote terminals, an Administration can
  439. choose how they allocate their technical staff between local and centralized
  440. locations.
  441. .PP
  442. Because of these benefits, it is recommended that centralized
  443. maintenance and other operations capabilities be considered when specifying 
  444. new telecommunications systems and equipments. The general principles for 
  445. setting\(hyup, operating and maintaining a Telecommunication Management 
  446. Network (TMN) to support centralized maintenance and other operations are 
  447. given in 
  448. Recommendation\ M.30.
  449. .RT
  450. .sp 2P
  451. .LP
  452. \fB3\fR     \fBOverall maintenance philosophy\fR 
  453. .sp 1P
  454. .RT
  455. .sp 1P
  456. .LP
  457. 3.1
  458.     \fIMaintenance entity concepts\fR 
  459. .sp 9p
  460. .RT
  461. .PP
  462. In order to facilitate efficient maintenance, the telecommunication network 
  463. (analogue and digital) is divided into parts, called Maintenance 
  464. Entities (MEs), Maintenance Entity Assemblies (MEAs) and Maintenance
  465. Sub\(hyEntities (MSEs). Examples of MEs, MEAs and MSEs are given in Figures\ 
  466. 1, 2 and\ 3/M.20. 
  467. .RT
  468. .LP
  469. .rs
  470. .sp 23P
  471. .ad r
  472. \fBFigure 1/M.20, p. 1\fR 
  473. .sp 1P
  474. .RT
  475. .ad b
  476. .RT
  477. .LP
  478. .bp
  479. .LP
  480. .rs
  481. .sp 19P
  482. .ad r
  483. \fBFigure 2/M.20, p. 2\fR 
  484. .sp 1P
  485. .RT
  486. .ad b
  487. .RT
  488. .LP
  489. .rs
  490. .sp 19P
  491. .ad r
  492. \fBFigure 3/M.20, p. 3\fR 
  493. .sp 1P
  494. .RT
  495. .ad b
  496. .RT
  497. .sp 1P
  498. .LP
  499. 3.1.1
  500.     \fIDefinition of\fR 
  501. \fIMaintenance Entity\fR 
  502. .sp 9p
  503. .RT
  504. .PP
  505. Maintenance entities are defined by the following
  506. principles:
  507. .RT
  508. .LP
  509.     \(em
  510.     The different equipments of a telecommunications network
  511. constituting the MEs are interconnected at consecutive and
  512. easily identifiable interface points at which points the
  513. interface conditions defined for these equipments apply and
  514. which possess the means of detecting maintenance events and
  515. failures.
  516. .FS
  517. If an easily identifiable interface point is not
  518. available, the interface point may be replaced by a point
  519. permitting sectionalization with functions such as,
  520. e.g.,\ looping\(hyback or performance monitoring.
  521. .FE
  522. .bp
  523. .LP
  524.     \(em
  525.     If the telecommunication equipment supports bidirectional
  526. transmission, it normally consists of telecommunications
  527. equipment transmitting in both directions and then both
  528. directions are considered part of the same ME.
  529. .LP
  530.     \(em
  531.     When a failure occurs within a network, it is desirable that
  532. the maintenance alarm indication appears at the failed
  533. maintenance entity. When this is not practical, the
  534. indication should appear at the closest possible entity.
  535. .LP
  536.     \(em
  537.     Maintenance alarm information indications in an entity should
  538. not cause related alarm information indications at other
  539. entities. In the event that such indications are permitted to
  540. occur, they should clearly indicate that the failure has
  541. occurred upstream, and not in the other entities displaying
  542. the information.
  543. .PP
  544. Meeting these four principles ensures that the responsible
  545. maintenance personnel are called into action, and that usually no unnecessary 
  546. maintenance activity is initiated elsewhere. 
  547. .PP
  548. In an integrated digital network, for example, easily identifiable
  549. points may be provided by digital distribution frames. Even in a location 
  550. where no digital distribution frame is provided, an equivalent point, where 
  551. defined interface conditions apply, will normally be identifiable. The 
  552. interface 
  553. between the exchange terminals and the digital switch may be accessed on a
  554. virtual basis.
  555. .RT
  556. .PP
  557. 3.1.2
  558. An ME has to perform a determined function between transmission interfaces 
  559. (see Figure\ 4/M.20). The performance is checked by internal failure detection 
  560. and conveyed to the maintenance interface either automatically after a 
  561. failure occurrence, or after a request for maintenance information. 
  562. .sp 9p
  563. .RT
  564. .LP
  565. .rs
  566. .sp 13P
  567. .ad r
  568. \fBFigure 4/M.20, p.\fR 
  569. .sp 1P
  570. .RT
  571. .ad b
  572. .RT
  573. .PP
  574. In addition, other operations and administrative functions may be carried 
  575. out by the maintenance interface. Several types of maintenance 
  576. interfaces are described in Recommendation\ M.30 which covers the TMN.
  577. .sp 1P
  578. .LP
  579. 3.1.3
  580.     \fIDefinition of\fR 
  581. \fIMaintenance Entity Assembly\fR 
  582. .sp 9p
  583. .RT
  584. .PP
  585. A maintenance entity assembly (MEA) is defined by the following
  586. principles:
  587. .RT
  588. .LP
  589.     \(em
  590.     An MEA contains a group of MEs assembled for additional
  591. maintenance purposes.
  592. .LP
  593.     \(em
  594.     Principles that apply for MEs apply also for MEAs.
  595. .LP
  596.     \(em
  597.     An MEA may detect failures and maintenance event
  598. information which can not be detected by MEs.
  599. .LP
  600.     \(em
  601.     An MEA may provide end\(hyto\(hyend maintenance alarm
  602. information which can not be provided by MEs.
  603. .PP
  604. End\(hyto\(hyend information may be collected by using additional
  605. supervision means.
  606. .bp
  607. .sp 1P
  608. .LP
  609. 3.1.4
  610.     \fIDefintion of\fR 
  611. \fIMaintenance Sub\(hyEntity\fR \fI(MSE)\fR 
  612. .sp 9p
  613. .RT
  614. .PP
  615. A maintenance sub\(hyentity is defined by the following
  616. principles:
  617. .RT
  618. .LP
  619.     \(em
  620.     The different parts of an MSE constituting the MEs are
  621. interconnected at consecutive and easily identifiable interface
  622. points.
  623. .LP
  624.     \(em
  625.     When a failure occurs within an MSE, it is desirable that
  626. the maintenance alarm information indication appears at the
  627. failed maintenance entity containing the MSE.
  628. .LP
  629.     \(em
  630.     An failed MSE should be identified as failed by the fault
  631. location process, but should lead only to the identification
  632. of the failed ME by the supervision process.
  633. .LP
  634.     \(em
  635.     An MSE generally corresponds to the item which is
  636. replaceable during routine operations in the event of a
  637. failure.
  638. .PP
  639. 3.1.5
  640. The choice of ME, MEA and MSE should be compatible with the
  641. maintenance organization of an Administration (Recommendations\ M.710, M.715
  642. to\ M.725).
  643. .sp 9p
  644. .RT
  645. .sp 1P
  646. .LP
  647. 3.1.6
  648.     \fIRelationship between Maintenance Entities and Network Elements\fR 
  649. .sp 9p
  650. .RT
  651. .PP
  652. The relationship between maintenance entities and network elements is defined 
  653. in Recommendation\ M.30. 
  654. .RT
  655. .sp 1P
  656. .LP
  657. 3.2
  658.     \fIFailure concepts\fR 
  659. .sp 9p
  660. .RT
  661. .PP
  662. The following definitions and classifications are used in
  663. developing the concept of a failure.
  664. .RT
  665. .sp 1P
  666. .LP
  667. 3.2.1
  668.     \fIAnomalies\fR 
  669. .sp 9p
  670. .RT
  671. .PP
  672. An anomaly is a discrepancy between the actual and desired
  673. characteristics of an item.
  674. .PP
  675. The desired characteristic may be expressed in the form of a
  676. specification.
  677. .PP
  678. An anomaly may or may not affect the ability of an item to perform a required 
  679. function. 
  680. .PP
  681. As an example, for a multiplexer one type of elementary information
  682. that can be detected is an error in the frame alignment word. This elementary 
  683. information is an anomaly. More examples of anomalies are given in 
  684. Recommendation\ M.550.
  685. .RT
  686. .sp 1P
  687. .LP
  688. 3.2.2
  689.     \fIDefects\fR 
  690. .sp 9p
  691. .RT
  692. .PP
  693. A defect is a limited interruption in the ability of an item to
  694. perform a required function. It may or may not lead to maintenance action
  695. depending on the results of additional analysis.
  696. .PP
  697. Successive anomalies causing a decrease in the ability of an item to perform 
  698. a required function are considered as a defect. 
  699. .PP
  700. As an example, the G.700 [3] series recommends that three consecutive errored 
  701. frame alignment words will give a loss of frame alignment. This loss of 
  702. frame alignment is a defect. More examples of defects are given in 
  703. Recommendation\ M.550.
  704. .PP
  705. The process of using anomalies and defects is explained in
  706. \(sc\ 3.3.
  707. .RT
  708. .sp 1P
  709. .LP
  710. 3.2.3
  711.     \fIFailures\fR 
  712. .sp 9p
  713. .RT
  714. .PP
  715. A failure is the termination of the ability of an item to perform a required 
  716. function. 
  717. .PP
  718. Analysis of successive anomalies or defects affecting the same item
  719. can lead to the item being considered as \*Qfailed\*U.
  720. .RT
  721. .sp 1P
  722. .LP
  723. 3.2.3.1
  724.     \fIClassification of failures\fR 
  725. .sp 9p
  726. .RT
  727. .PP
  728. The severity of the failure depends on the failure effect. This
  729. effect can be related to:
  730. .RT
  731. .LP
  732.     \(em
  733.     the network service performance requirements as
  734. experienced by the subscribers;
  735. .LP
  736.     \(em
  737.     the probability that multiple failures will occur, thus
  738. resulting in a deteriorating performance as seen by the
  739. customer;
  740. .LP
  741.     \(em
  742.     the probable loss of revenue to the Administration.
  743. .bp
  744. .PP
  745. The failures can be classified according to their importance and consequences 
  746. to the quality of service provided to the subscribers and to the network 
  747. technical performance: 
  748. .LP
  749.     \(em
  750.     failures which result in complete interruption of service(s)
  751. for one or several subscribers;
  752. .LP
  753.     \(em
  754.     failures which result in partial interruption of service(s)
  755. (e.g.\ degradation of transmission quality) to one or several
  756. subscribers;
  757. .LP
  758.     \(em
  759.     failures which decrease the availability performance of
  760. the equipment and/or the network but do not affect the
  761. subscribers.
  762. .LP
  763.     \(em
  764.     A failure can be either a permanent or intermittent
  765. condition and this may alter its effect on the network.
  766. .LP
  767.     \(em
  768.     The severity of a failure can be determined by measuring the
  769. down time, up time and failure rate of the ME. These items are
  770. defined in Supplement No.\ 6 to Fascicle\ II.3\ [4].
  771. .sp 1P
  772. .LP
  773. 3.2.4
  774.     \fIFault\fR 
  775. .sp 9p
  776. .RT
  777. .PP
  778. A fault is the inability of an item to perform a required function, excluding 
  779. that inability due to preventive maintenance, lack of external 
  780. resources or planned actions.
  781. .PP
  782. \fINote\fR \ \(em\ A fault is often the result of a failure of the item 
  783. itself, but may exist without prior failure. 
  784. .RT
  785. .sp 1P
  786. .LP
  787. 3.3
  788.     \fINetwork supervision\fR 
  789. .sp 9p
  790. .RT
  791. .PP
  792. Network supervision is a process in which the anomalies and defects detected 
  793. by the maintenance entities ME or MEA are analyzed and checked. This analysis 
  794. may be internal or external to the entity. In the external case it can 
  795. be accomplished either locally or on a centralized basis. 
  796. .PP
  797. For maintenance, this supervision process has to include the following actions:
  798. .RT
  799. .LP
  800.     a)
  801.     Locating \*Qfailed\*U equipment, or the equipment in which a
  802. fault is suspected or a failure is believed to be imminent. It
  803. is generally carried out by analytical or statistical
  804. identification processes. The supervision process consists of
  805. three continuously running concurrent processes:
  806. .LP
  807.     \(em
  808.     the supervisory process for anomalies (short period),
  809. .LP
  810.     \(em
  811.     the defect supervisory process (medium period), and
  812. .LP
  813.     \(em
  814.     the malfunction supervisory process (long period).
  815. .LP
  816.     Each process is interfaced by the characteristic data,
  817. e.g.\ accumulated anomaly data and accumulated defect data. The
  818. supervisory processes for anomalies and defects respectively,
  819. indicate that the anomaly or defect states have been reached.
  820. The malfunction supervisory process evaluates the performance
  821. level of the maintenance entity and judges it to be normal,
  822. degraded or unacceptable. These levels are determined from the
  823. anomalies and defects received and analyzed over a given time.
  824. The thresholds limiting degraded or unacceptable performance
  825. limits and the process period are defined for each defect and
  826. confirmed fault or group of anomalies and defects and also for
  827. each type of entity. Indications of degraded and unacceptable
  828. performance levels are generated each time the corresponding
  829. threshold is exceeded. This process is shown in Figure\ 5/M.20.
  830. .LP
  831.     b)
  832.     Reporting of failures to maintenance personnel.
  833. .LP
  834.     c)
  835.     Transmission of data to the maintenance personnel,
  836. relating to specific functional features of the network
  837. (traffic, state of equipment, particular malfunctions,\ etc.).
  838. This information can be transmitted systematically or on
  839. demand.
  840. .LP
  841.     d)
  842.     Protecting the system by transmitting to all concerned
  843. network equipment the necessary information for automatic
  844. initialization of internal or external protection mechanisms,
  845. e.g.,\ reconfiguration, traffic rerouting,\ etc.
  846. .LP
  847.     e)
  848.     Modify the supervision process due to:
  849. .LP
  850.     \(em
  851.     the type of service being offered over a given
  852. portion of the network;
  853. .LP
  854.     \(em
  855.     the time of day.
  856. .bp
  857. .LP
  858. .rs
  859. .sp 47P
  860. .ad r
  861. \fBFigure 5/M.20, p.\fR 
  862. .sp 1P
  863. .RT
  864. .ad b
  865. .RT
  866. .LP
  867. .bp
  868. .sp 2P
  869. .LP
  870. \fB4\fR \fBBringing new international transmission systems and circuits\fR 
  871. \fBinto service\fR 
  872. .sp 1P
  873. .RT
  874. .sp 1P
  875. .LP
  876. 4.1
  877.     \fIInstallation and acceptance testing\fR 
  878. .FS
  879. Installation and
  880. acceptance testing is not generally considered part of maintenance.
  881. .FE
  882. .sp 9p
  883. .RT
  884. .PP
  885. For new systems, this work may include the necessary installation of new 
  886. equipment. Once the new equipment is working, the Administration should 
  887. make the necessary tests to ensure the new system meets required 
  888. specifications. Acceptance testing of the new system or equipments should be
  889. based on policies established by the Administration. However, Administrations 
  890. may wish to use the performances monitoring techniques found in 
  891. Recommendation\ M.24 to aid in their acceptance testing of new transmission
  892. systems.
  893. .RT
  894. .sp 1P
  895. .LP
  896. 4.2
  897.     \fISetting\(hyup and lining\(hyup\fR 
  898. .sp 9p
  899. .RT
  900. .PP
  901. As soon as Administrations have decided to bring a new
  902. international transmission system and/or circuit into service, the necessary
  903. contacts are made between their technical service for the exchange of
  904. information. Those services jointly select the control and sub\(hycontrol 
  905. stations for the new system or circuit (see Recommendations\ M.80 and\ 
  906. M.90). 
  907. .PP
  908. The technical service of each Administration is responsible for the
  909. setting\(hyup and lining\(hyup of the line or circuit sections in its territory, 
  910. and for arranging that the adjustments and tests required are made by the 
  911. station staff concerned. 
  912. .RT
  913. .sp 1P
  914. .LP
  915. 4.3
  916.     \fIDetailed considerations\fR 
  917. .sp 9p
  918. .RT
  919. .PP
  920. To set\(hyup a line section or circuit which crosses a frontier,
  921. Administrations should arrive at bilateral agreements on the basis of CCITT
  922. Recommendations and, for radio\(hyrelay sections, the Recommendations of 
  923. the CCIR. Administrations should refer to the following Recommendations 
  924. for detailed 
  925. considerations associated with bringing into service the following
  926. entities:
  927. .RT
  928. .sp 1P
  929. .LP
  930. 4.3.1
  931.     \fINew transmission systems\fR 
  932. .sp 9p
  933. .RT
  934. .PP
  935. CCITT Volume IV, \(sc\ 2.3, Recommendations M.450 through M.480 and
  936. M.24.
  937. .RT
  938. .sp 1P
  939. .LP
  940. 4.3.2
  941.     \fITelephone circuits\fR 
  942. .sp 9p
  943. .RT
  944. .PP
  945. CCITT Volume IV, \(sc\ 3.1, Recommendations M.570 through M.590.
  946. .RT
  947. .sp 1P
  948. .LP
  949. 4.3.3
  950.     \fICommon channel signalling systems\fR 
  951. .sp 9p
  952. .RT
  953. .PP
  954. CCITT Volume IV, \(sc\ 4, Recommendations M.761 and M.782.
  955. .RT
  956. .sp 1P
  957. .LP
  958. 4.4
  959.     \fIBringing into service\fR 
  960. .sp 9p
  961. .RT
  962. .PP
  963. After the control station has determined from reports provided by the subcontrol 
  964. station that appropriate tests and adjustments have been 
  965. performed, the control station conducts overall tests of the system or 
  966. circuit. The overall tests results are recorded, operations systems data 
  967. bases are 
  968. updated and synchronized between Administrations, and the system and/or
  969. circuits are placed in service. At this time the system and/or circuits are
  970. transferred to a performance measuring state (see \(sc\ 5.1) to track and 
  971. insure 
  972. their continuing proper operation.
  973. .RT
  974. .sp 2P
  975. .LP
  976. \fB5\fR     \fBMaintenance phases under normal and fault conditions\fR 
  977. .sp 1P
  978. .RT
  979. .PP
  980. Under normal conditions in the network, performance information
  981. should be gathered from MEs on a continuous or periodic basis. This data 
  982. can be used to detect acute fault conditions which generate alarm reports. 
  983. Further 
  984. analysis may reveal subtle degradations which generate maintenance information 
  985. reports. 
  986. .PP
  987. After the occurrence of a failure in the network, a number of
  988. maintenance phases are required to correct the fault and to protect, when
  989. possible, the traffic affected by the fault if it has been interrupted.
  990. .PP
  991. As an example, Figure 6/M.20 lists the maintenance phases which are
  992. involved before and after a failure occurrence in a maintenance entity (ME).
  993. The parameters determining the different phases are indicated in the figure. 
  994. It is intended to characterize different maintenance strategies with the 
  995. aid of 
  996. the maintenance phases. The mechanics used to implement the various maintenance 
  997. processes should be defined in connection with each specific application 
  998. in the relevant Recommendations. The maintenance phases are described below 
  999. in more 
  1000. detail.
  1001. .bp
  1002. .RT
  1003. .LP
  1004. .rs
  1005. .sp 47P
  1006. .ad r
  1007. \fBFigure 6/M.20, p.\fR 
  1008. .sp 1P
  1009. .RT
  1010. .ad b
  1011. .RT
  1012. .LP
  1013. .bp
  1014. .sp 1P
  1015. .LP
  1016. 5.1
  1017.     \fIPerformance measuring\fR 
  1018. .sp 9p
  1019. .RT
  1020. .PP
  1021. Different types of performance measuring mechanisms can be
  1022. used:
  1023. .RT
  1024. .LP
  1025.     a)
  1026.     continuous checking,
  1027. .LP
  1028.     b)
  1029.     routine or periodic testing,
  1030. .LP
  1031.     c)
  1032.     checking of behavior in live traffic,
  1033. .LP
  1034.     d)
  1035.     checking of behavior in the absence of live traffic.
  1036. .PP
  1037. The rules governing the measurement mechanisms are defined when
  1038. conceiving the systems; no intervention of the maintenance personnel is
  1039. necessary. Under some conditions, however, the personnel can control some
  1040. operations which may prove necessary for periodic or casual checking,
  1041. such as:
  1042. .LP
  1043.     \(em
  1044.     modifying the priority level of a checking process;
  1045. .LP
  1046.     \(em
  1047.     modifying the nominal period in the case of periodical
  1048. checking;
  1049. .LP
  1050.     \(em
  1051.     carrying out some partial or recurrent checks
  1052. (e.g. test on demand).
  1053. .PP
  1054. The choice of a measurement mechanism depends on the requirements for the 
  1055. \*Qquality of service\*U as seen by the subscribers, and on the technical 
  1056. network performance and the nature of the equipment. In addition, several 
  1057. mechanisms may be operated in the same item of equipment.
  1058. .PP
  1059. Typical measurement mechanisms are listed below.
  1060. .RT
  1061. .sp 1P
  1062. .LP
  1063. 5.1.1
  1064.     \fIContinuous checking\fR 
  1065. .sp 9p
  1066. .RT
  1067. .PP
  1068. All the time an item is active, it is being checked for good
  1069. performance. If the item does not fulfill the test requirements, it is
  1070. considered to have failed.
  1071. .RT
  1072. .sp 1P
  1073. .LP
  1074. 5.1.2
  1075.     \fIRoutine or periodic testing\fR 
  1076. .sp 9p
  1077. .RT
  1078. .PP
  1079. Items are tested periodically, initiated either by the system or by the 
  1080. maintenance staff. 
  1081. .PP
  1082. The frequency of the test depends on the importance of the item, the failure 
  1083. rate and the number of items of that type present in the element. 
  1084. .RT
  1085. .sp 1P
  1086. .LP
  1087. 5.1.3
  1088.     \fIChecking in live traffic\fR 
  1089. .sp 9p
  1090. .RT
  1091. .PP
  1092. Checking behavior in live traffic can be done directly or
  1093. statistically.
  1094. .PP
  1095. This checking exists if the ME itself indicates a failed performance or 
  1096. the continuous detection of anomalies or defects. 
  1097. .PP
  1098. All of the elementary information from the different detectors is
  1099. either retransmitted by each entity to a processing unit or processed locally.
  1100. .PP
  1101. Performance parameters are derived from this information.
  1102. .RT
  1103. .sp 1P
  1104. .LP
  1105. 5.1.3.1
  1106.     \fIProcessing of performance parameters\fR 
  1107. .sp 9p
  1108. .RT
  1109. .PP
  1110. Some performance parameters in use are Errored Seconds (ES),
  1111. Severely Errored Seconds (SES) and Degraded Minutes (DM). These particular 
  1112. parameters are defined in Recommendation\ G.821\ [5]. 
  1113. .PP
  1114. Each of the performance parameters (e.g., ES, SES, DM) is to be
  1115. processed separately in order to evaluate the performance level of the 
  1116. entity's operation. 
  1117. .RT
  1118. .sp 1P
  1119. .LP
  1120. 5.1.3.2
  1121.     \fIEvaluation of unacceptable performance\fR 
  1122. .sp 9p
  1123. .RT
  1124. .PP
  1125. Unacceptable performance
  1126. is characterized by a significant and long\(hylasting degradation in quality. 
  1127. It can be associated with the failed state. 
  1128. .PP
  1129. It is ascertained by statistical analysis of each of the performance parameters 
  1130. individually, throughout a given time T1. 
  1131. .PP
  1132. As soon as the result of statistical analysis reaches a N1 threshold (defined 
  1133. for each entity individually), the entity is declared to be at an 
  1134. unacceptable level of performance.
  1135. .PP
  1136. Elsewhere, for each defect corresponding to an interruption, lasting \fIx\fR 
  1137. consecutive seconds, the entity is considered as having reached an 
  1138. unacceptable level.
  1139. .bp
  1140. .RT
  1141. .sp 1P
  1142. .LP
  1143. 5.1.3.3
  1144.     \fIEvaluation of degraded performance\fR 
  1145. .sp 9p
  1146. .RT
  1147. .PP
  1148. Each of the performance parameters is analyzed statistically over a time 
  1149. T2 which can be a relatively long period. 
  1150. .PP
  1151. As soon as the result of statistical analysis reaches a N2 threshold (to 
  1152. be defined), the entity can be considered to be at degraded performance. 
  1153. The time T2 will depend on the entity in question.
  1154. .PP
  1155. This checking leads to maintenance decisions on statistical
  1156. grounds:
  1157. .RT
  1158. .LP
  1159.     \(em
  1160.     the number of times in which the item performs its
  1161. function \*Qnormally\*U is compared with the number of times the
  1162. performance of the item does not fulfill the requirements;
  1163. .LP
  1164.     \(em
  1165.     the average time of functioning is compared with standard
  1166. values;
  1167. .LP
  1168.     \(em
  1169.     the number of times an item performs its function during a
  1170. certain period is compared to normal values.
  1171. .PP
  1172. If the degraded performance level is characterized by a gradual
  1173. degradation in quality, the maintenance personnel should be informed before
  1174. this decrease in performance becomes unacceptable to the user.
  1175. .sp 1P
  1176. .LP
  1177. 5.1.4
  1178.     \fIChecking in the absence of live traffic\fR \fI(traffic\fR 
  1179. \fIis zero)\fR 
  1180. .sp 9p
  1181. .RT
  1182. .PP
  1183. Checking of system internal functions is done once a process is
  1184. over, or when a process has been initiated several times. Examples are
  1185. operational checks which start when a customer initiates an action to use 
  1186. the network. 
  1187. .RT
  1188. .sp 1P
  1189. .LP
  1190. 5.2
  1191.     \fIFailure detection\fR 
  1192. .sp 9p
  1193. .RT
  1194. .PP
  1195. Failures should be discovered by the Administration independently of, and 
  1196. preferably before, the subscriber, i.e., the majority of failures are both 
  1197. detected and remedied without the subscriber having been aware of them. 
  1198. .PP
  1199. Failures are classified depending on their nature (see \(sc 3.2) and may 
  1200. be categorized depending on their severity. Corresponding maintenance alarm 
  1201. information is then passed on to the appropriate entities.
  1202. .RT
  1203. .sp 1P
  1204. .LP
  1205. 5.3
  1206.     \fISystem protection\fR 
  1207. .sp 9p
  1208. .RT
  1209. .PP
  1210. When a failure has occurred or performance has degraded, the
  1211. following functions must be performed:
  1212. .RT
  1213. .LP
  1214.     \(em
  1215.     as a result of the medium and longer period supervision
  1216. process a signal must be transmitted to all the concerned
  1217. network equipment of any necessary information for automatic
  1218. (preferred) initialization of internal or external protection
  1219. mechanisms, e.g.,\ reconfiguration, traffic rerouting,\ etc.;
  1220. .LP
  1221.     \(em
  1222.     decision on any necessary actions, e.g. putting an item
  1223. \*Qout of service\*U or \*Qin testing condition\*U, changing to a
  1224. configuration with minimal or degraded service.
  1225. .PP
  1226. A specific protection method is recommended for transmission
  1227. systems using manual or automatic restoration on a maintenance entity
  1228. basis:
  1229. .LP
  1230.     a)
  1231.     If a failure occurs either in maintenance entities without
  1232. automatic changeover capabilities or with automatic changeover
  1233. capabilities but no standby available, the following actions
  1234. should be executed:
  1235. .LP
  1236.     1)
  1237.     initiate maintenance alarm information identifying
  1238. the maintenance entity containing the failed equipment;
  1239. .LP
  1240.     2)
  1241.     transmit an alarm indication signal (AIS) in
  1242. the direction affected (downstream direction) or give an
  1243. upstream failure indication (UFI) at equipment which
  1244. has not failed;
  1245. .LP
  1246.     3)
  1247.     initiate a service alarm indication at the appropriate
  1248. entities, e.g.\ primary PCM multiplex or digital switch
  1249. interfaces. (As a consequence the circuits may be removed
  1250. from service.)
  1251. .LP
  1252.     b)
  1253.     If a failure occurs in a maintenance entity having automatic
  1254. changeover capability with a standby available, the following
  1255. actions should be automatically executed:
  1256. .LP
  1257.     1)
  1258.     changeover to the standby;
  1259. .LP
  1260.     \fINote\fR \ \(em\ Whether or not connections are released as a
  1261. result of automatic changeover depends on the service
  1262. performance objectives assigned to each maintenance
  1263. entity.
  1264. .LP
  1265.     2)
  1266.     initiate maintenance alarm information indicating
  1267. the maintenance entity containing the failed
  1268. equipment.
  1269. .bp
  1270. .sp 1P
  1271. .LP
  1272. 5.4
  1273.     \fIFailure or performance information\fR 
  1274. .sp 9p
  1275. .RT
  1276. .PP
  1277. Information on failure, unacceptable performance or degraded
  1278. performance will normally be transmitted to the maintenance staff and other
  1279. parts of the network notified when appropriate.
  1280. .PP
  1281. Information for the use of personnel is available either in the
  1282. entity, when the processing of anomalies or defects is internal, or via 
  1283. a unit which provides processing, when external to the entity. 
  1284. .RT
  1285. .sp 1P
  1286. .LP
  1287. 5.4.1
  1288.     \fIAlarm information categories\fR 
  1289. .sp 9p
  1290. .RT
  1291. .PP
  1292. The following maintenance alarm information may be associated with the 
  1293. information of failure or unacceptable or degraded performance: 
  1294. .RT
  1295. .LP
  1296.     a)
  1297.     \fIPrompt maintenance alarm (PMA)\fR 
  1298. .LP
  1299.     A prompt maintenance alarm is generated in order to
  1300. initiate maintenance activities (normally immediately) by
  1301. maintenance personnel to remove from service a defective
  1302. equipment for the purpose of restoring good service and
  1303. effecting repair of the failed equipment.
  1304. .LP
  1305.     b)
  1306.     \fIDeferred maintenance alarm (DMA)\fR 
  1307. .LP
  1308.     A deferred maintenance alarm is generated when immediate
  1309. action is not required by maintenance personnel, e.g.\ when
  1310. performance falls below standard but the effect does not
  1311. warrant removal from service, or generally if automatic
  1312. changeover to standby equipment has been used to restore
  1313. service.
  1314. .LP
  1315.     c)
  1316.     \fIMaintenance event information (MEI)\fR 
  1317. .LP
  1318.     This information has to be generated as a consequence of
  1319. events when no immediate actions by the maintenance staff are
  1320. required because the total performance is not endangered. The
  1321. maintenance actions can be performed on a scheduled basis or
  1322. after the accumulation of maintenance event information
  1323. indications.
  1324. .PP
  1325. Starting with the malfunction supervisory process from
  1326. Figure\ 5/M.20, Figure\ 7/M.20 shows the alarm informtion process for an 
  1327. ME. The actual PMA, DMA or MEI may or may not be generated in the ME. When 
  1328. generated 
  1329. outside the ME, the alarm information process may combine information from
  1330. other sources (e.g.,\ other MEs, time of day, traffic load,\ etc.) with the
  1331. output from the malfunction supervisory process to decide if a PMA, DMA or
  1332. MEI should be generated. When an AIS or UFI is received, an ME may be required 
  1333. to generate an SA. 
  1334. .PP
  1335. Both the malfunction supervisory process and the alarm information
  1336. process, including the use of PMAs, DMAs and MEIs, can also be applied 
  1337. to other non\(hytelecommunications equipment. 
  1338. .RT
  1339. .LP
  1340. .rs
  1341. .sp 22P
  1342. .ad r
  1343. \fBFigure 7/M.20, p.\fR 
  1344. .sp 1P
  1345. .RT
  1346. .ad b
  1347. .RT
  1348. .LP
  1349. .bp
  1350. .sp 1P
  1351. .LP
  1352. 5.4.2
  1353.     \fIOther fault and service indications\fR 
  1354. .sp 9p
  1355. .RT
  1356. .PP
  1357. In order to avoid unnecessary maintenance actions and to signal the unavailability 
  1358. of the service, the following fault indications are 
  1359. used:
  1360. .RT
  1361. .LP
  1362.     \(em
  1363.     Alarm indication signal (AIS)
  1364. .LP
  1365.     An alarm indication signal (AIS) is a signal associated
  1366. with a defective maintenance entity and is, when
  1367. possible, transmitted in the direction affected (downstream
  1368. direction) as a substitute for the normal signal, indicating to
  1369. other nondefective entities that a failure has been identified
  1370. and that other maintenance alarms consequent to this failure
  1371. should be inhibited. The binary equivalent of the AIS
  1372. corresponds to an all 1s\ signal.
  1373. .LP
  1374.     \fINote\ 1\fR \ \(em\ The AIS is different from the \*Qalarm
  1375. information to the remote end\*U; see \(sc\ 5.4.4.
  1376. .LP
  1377.     \fINote\ 2\fR \ \(em\ The AIS capability does not impose any
  1378. restrictions on the binary content of signals which may be
  1379. transmitted over the digital hierarchy at the primary multiplex
  1380. and higher levels. The implications at the 64\(hykbit/s level and
  1381. at lower bit rates are under study, since ambiguity arises
  1382. between AIS and an all\ 1s information signal.
  1383. .LP
  1384.     \fINote\ 3\fR \ \(em\ For a maintenance entity with multidestination
  1385. ends (e.g. in networks with TDMA/DSI satellite systems) alarm
  1386. indication signals on a circuit basis may useful. This subject
  1387. is under study.
  1388. .LP
  1389.     \fINote\ 4\fR \ \(em\ In the particular case of the 44 736 kbit/s
  1390. hierarchical level, the AIS is defined as a signal:
  1391. .LP
  1392.     i)
  1393.     with a valid frame alignment signal, parity and
  1394. justification control bits as defined in Table\ 2/G.752\ [6];
  1395. .LP
  1396.     ii)
  1397.     with the tributary bits being set to a 1010 |  |  | 
  1398. sequence, starting with a binary one (\*Q1\*U) after each frame
  1399. alignment, multiframe alignment and justification control bit;
  1400. .LP
  1401.     iii)
  1402.     and with all justification control bits being set to
  1403. binary zero (\*Q0\*U).
  1404. .LP
  1405.     Demultiplexers of the 44 | 36 kbit/s hierarchical level must
  1406. produce the all 1s AIS at their tributary outputs when they
  1407. receive the 44 | 36\ kbit/s AIS at their high speed inputs.
  1408. .LP
  1409.     \(em
  1410.     Service alarm (SA)
  1411. .LP
  1412.     A service alarm is generated at maintenance entities at
  1413. which the service originates and/or terminates to indicate that
  1414. the particular service is no longer available (e.g.\ when a
  1415. primary block is no longer available for setting up connections,
  1416. the PCM muldex will extend a service alarm indication to the
  1417. exchange equipment).
  1418. .LP
  1419.     The service alarm should be generated when performance falls
  1420. below a level specified for a particular service. This level may
  1421. coincide with that for initiating also a prompt maintenance
  1422. alarm.
  1423. .LP
  1424.     \(em
  1425.     Upstream failure indication (UFI)
  1426. .LP
  1427.     The upstream failure indication given by a
  1428. maintenance entity indicates that the signal arriving at that
  1429. maintenance entity is defective. The UFI indicates that the
  1430. failure has occurred upstream of this point, and no unnecessary
  1431. maintenance activities are initiated.
  1432. .LP
  1433.     The appearance of an alarm indicates either a fault in the
  1434. equipment generating the alarm or a failure of the incoming
  1435. signal (an upstream failure). To distinguish between these two
  1436. possibilities it is necessary to provide an independent test,
  1437. either of the input signal, or of the equipment generating the
  1438. alarm. The input signal can be checked for proper parity,
  1439. for example, by a monitor included in the protection switching
  1440. equipment. A defective input signal indicates an upstream
  1441. failure. Alternatively, the equipment generating the alarm can
  1442. be tested independently, by looping, for example, and if the
  1443. equipment operates correctly, an upstream failure is
  1444. indicated.
  1445. .PP
  1446. \fINote\fR \ \(em\ For a multiple destination maintenance entity (e.g. in
  1447. networks with TDMA/DSI satellite systems) alarm indication signals on a 
  1448. circuit basis may be useful. This subject is under study. 
  1449. .sp 1P
  1450. .LP
  1451. 5.4.3
  1452.     \fITransmission and presentation of alarm information\fR 
  1453. .sp 9p
  1454. .RT
  1455. .PP
  1456. The failure information at the alarm interface is used to determine the 
  1457. faulty ME or part of ME. The information can be presented either locally, 
  1458. or remotely via an alarm collection system. 
  1459. .PP
  1460. The alarms may be presented as:
  1461. .RT
  1462. .LP
  1463.     \(em
  1464.     an indication at an alarm interface (e.g.\ contact function,
  1465. d.c. signal)
  1466. .LP
  1467.     \(em
  1468.     an alarm message on the man\(hymachine interface.
  1469. .bp
  1470. .sp 1P
  1471. .LP
  1472. 5.4.4
  1473.     \fIAlarm information to the remote end\fR 
  1474. .sp 9p
  1475. .RT
  1476. .PP
  1477. Equipment which is a source of digital multiple signals (i.e.
  1478. multiple equipment or exchanges) may, in case of a fault condition, transmit
  1479. alarm information within a specified bit or specified bits of the pulse
  1480. frame. This information is intended for evaluation at the remote terminal 
  1481. (at the end of the digital link). Examples: see Recommendation\ G.704, 
  1482. \(sc\ 2.3.2\ [7], Recommendation\ G.732, \(sc\ 4.2.3\ [8] and Recommendation\ 
  1483. G.733, \(sc\ 4.2.4\ [9]. 
  1484. .RT
  1485. .sp 1P
  1486. .LP
  1487. 5.5
  1488.     \fIFault localication\fR 
  1489. .sp 9p
  1490. .RT
  1491. .PP
  1492. Where the initial failure information is insufficient for fault
  1493. localization within a failing ME, it has to be augmented with information
  1494. obtained by additional fault localization routines. The routines can employ
  1495. ME internal or external test systems, initiated manually or automatically, 
  1496. at the local and/or remote end. 
  1497. .PP
  1498. A test system, serving one or more MEs could have the following
  1499. functions:
  1500. .RT
  1501. .LP
  1502.     \(em
  1503.     alarm collection, e.g.\ by sampling of alarm interfaces and
  1504. assembling of alarm messages;
  1505. .LP
  1506.     \(em
  1507.     request for failure information, e.g.\ by addressing
  1508. different MEs;
  1509. .LP
  1510.     \(em
  1511.     test programs, e.g.\ for selection of essential alarms,
  1512. editing, etc.;
  1513. .LP
  1514.     \(em
  1515.     control of special devices, e.g.\ for looping measurement of
  1516. electrical characteristics;
  1517. .LP
  1518.     \(em
  1519.     display of results, e.g.\ for all MEs within a
  1520. network region.
  1521. .PP
  1522. It should be particularly noted that:
  1523. .LP
  1524.     \(em
  1525.     the corrective maintenance action time and the activity of
  1526. repair centres (these repair centres may receive unfailed items
  1527. or sub\(hyitems) are strongly conditioned by the localization
  1528. efficiency (not yet defined);
  1529. .LP
  1530.     \(em
  1531.      if an ME can be subdivided into MSEs, the faulty MSE should be identified 
  1532. as failed in the fault localization process; 
  1533. .LP
  1534.     \(em
  1535.     for interchangeable items, the failed item must be identified uniquely.
  1536. .sp 2P
  1537. .LP
  1538. 5.6
  1539.     \fILogistic delay\fR 
  1540. .sp 1P
  1541. .RT
  1542. .PP
  1543. 5.6.1
  1544. The logistic delay is the period of time between the
  1545. fault localization and arrival of the maintenance staff of site. In the case
  1546. of an ISDN, the logistic delay will depend on the type of failures and how
  1547. they are reported, i.e.\ by PMA, DMA or\ MEI.
  1548. .sp 9p
  1549. .RT
  1550. .PP
  1551. 5.6.2
  1552. Following a PMA or DMA alarm, fault correction will be
  1553. performed normally in the course of a specific trip of the maintenance 
  1554. staff. The logistic delay may vary from a few hours in the case of PMA 
  1555. alarms, to 
  1556. a few days in the case of DMA alarms.
  1557. .PP
  1558. 5.6.3
  1559. Following an MEI, which indicates that no immediate actions are
  1560. necessary, the maintenance action can be postponed until the next scheduled
  1561. maintenance visit unless an accumulation of MEIs demands earlier action.
  1562. .sp 1P
  1563. .LP
  1564. 5.7
  1565.     \fIFault correction\fR 
  1566. .sp 9p
  1567. .RT
  1568. .PP
  1569. Fault correction normally requires change or repair of an ME, MSE or a 
  1570. part thereof. One or more fault corrections can be performed in the course 
  1571. of a maintenance visit. It is desirable that strategies be developed to 
  1572. accomplish fault correction satisfying overall maintenance objectives with a
  1573. minimum number of visits, using the concept of logistic delay.
  1574. .PP
  1575. Failed interchangeable items will be sent to a specialized repair
  1576. centre, where appropriate test equipment is available (the system itself 
  1577. should not act as a test machine). 
  1578. .PP
  1579. Normally, cooperation between maintenance elements in different
  1580. Administrations will result in the satisfactory identification and correction 
  1581. of faults. There may be circumstances, however, where the fault escalation 
  1582. procedure defined in Recommendation\ M.711 may be required.
  1583. .RT
  1584. .sp 1P
  1585. .LP
  1586. 5.8
  1587.     \fIVerification\fR 
  1588. .sp 9p
  1589. .RT
  1590. .PP
  1591. After the fault has been corrected, checks must be made to assure the ME 
  1592. is working properly. The verification can be made locally or 
  1593. remotely.
  1594. .bp
  1595. .RT
  1596. .sp 1P
  1597. .LP
  1598. 5.9
  1599.     \fIRestoration\fR 
  1600. .sp 9p
  1601. .RT
  1602. .PP
  1603. The corrected part of the ME or MSE is restored to service. Blocked MEs 
  1604. are deblocked and changeover to spare may be terminated. 
  1605. .RT
  1606. .sp 2P
  1607. .LP
  1608. \fB6\fR     \fBAdditional maintenance activities\fR 
  1609. .sp 1P
  1610. .RT
  1611. .PP
  1612. Besides the above\(hymentioned phases, the following activities may be 
  1613. required. 
  1614. .RT
  1615. .sp 1P
  1616. .LP
  1617. 6.1
  1618.     \fIMaintenance support\fR 
  1619. .sp 9p
  1620. .RT
  1621. .PP
  1622. Maintenance support covers the functions identified below:
  1623. .RT
  1624. .LP
  1625.     \(em
  1626.     management of information of network equipment in operation,
  1627. .LP
  1628.     \(em
  1629.     management of operating data (routing data mainly),
  1630. .LP
  1631.     \(em
  1632.     correction instruction for hardware and software,
  1633. .LP
  1634.     \(em
  1635.     repairing of removable items,
  1636. .LP
  1637.     \(em
  1638.     management of maintenance stocks,
  1639. .LP
  1640.     \(em
  1641.     network and equipment documentation.
  1642. .PP
  1643. The quantity of spare parts held depends on:
  1644. .LP
  1645.     \(em
  1646.     organization of maintenance entities,
  1647. .LP
  1648.     \(em
  1649.     failure rate of an item,
  1650. .LP
  1651.     \(em
  1652.     turn around time (actual repair time, transport),
  1653. .LP
  1654.     \(em
  1655.     number of items in operation,
  1656. .LP
  1657.     \(em
  1658.     risk that no spare part is available.
  1659. .sp 1P
  1660. .LP
  1661. 6.2
  1662.     \fIFailure statistics\fR 
  1663. .sp 9p
  1664. .RT
  1665. .PP
  1666. If all failures are recorded, this information, after processing, can serve 
  1667. the following organizational fields: 
  1668. .RT
  1669. .LP
  1670.     a)
  1671.     management, e.g.\ evaluating system performance,
  1672. .LP
  1673.     b)
  1674.     organization of maintenance, e.g.\ use of test equipment,
  1675. subscriber complaints versus test results, amount of spare parts,
  1676. .LP
  1677.     c)
  1678.     maintenance activities, e.g. identifying weak components
  1679. where preventive maintenance actions are necessary.
  1680. .sp 1P
  1681. .LP
  1682. 6.3
  1683.     \fIPreventive maintenance actions\fR 
  1684. .sp 9p
  1685. .RT
  1686. .PP
  1687. Mechanical parts (such as magnetic equipment heads) have to be
  1688. cared for periodically.
  1689. .PP
  1690. After analyzing failure statistics, decisions can be made to
  1691. interchange items even before failures have occurred, if they seem to be 
  1692. weak items. 
  1693. .RT
  1694. .sp 2P
  1695. .LP
  1696. \fB7\fR     \fBOther maintenance considerations\fR 
  1697. .sp 1P
  1698. .RT
  1699. .sp 1P
  1700. .LP
  1701. 7.1
  1702.     \fIReference test frequency considerations\fR 
  1703. .sp 9p
  1704. .RT
  1705. .PP
  1706. (Under study.)
  1707. .RT
  1708. .sp 1P
  1709. .LP
  1710. 7.2
  1711.     \fIUse of maintenance test lines and loop\(hybacks\fR 
  1712. .sp 9p
  1713. .RT
  1714. .PP
  1715. (Under study.)
  1716. .RT
  1717. .sp 2P
  1718. .LP
  1719.     \fBReferences\fR 
  1720. .sp 1P
  1721. .RT
  1722. .LP
  1723. [1]
  1724.      CCITT Recommendation \fISpecification for CCITT automatic transmission\fR 
  1725. \fImeasuring and signalling testing equipment ATME No. 2\fR , Vol.\ IV, 
  1726. Rec.\ O.22.
  1727. .LP
  1728. [2]
  1729.     CCITT Supplement \fINew operation and maintenance organization in the\fR 
  1730. \fIMilan Italcable Intercontinental telecommunication centre\fR , Vol.\ IV,
  1731. Supplement No.\ 6.2.
  1732. .LP
  1733. [3]
  1734.     CCITT Recommendations of the G.700 Series \fIDigital networks\fR ,
  1735. Vol.\ III, Rec.\ G.700 to\ G.956.
  1736. .LP
  1737. [4]
  1738.     CCITT Supplement \fITerms and definitions for quality of service,\fR 
  1739. \fInetwork performance, dependability and trafficability studies\fR ,
  1740. Vol.\ II, Fascicle\ II.3, Supplement No.\ 6.
  1741. .bp
  1742. .LP
  1743. [5]
  1744.     CCITT Recommendation \fIError performance on an international digital\fR 
  1745. \fIconnection forming part of an integrated services digital network\fR ,
  1746. Vol.\ III, Rec.\ G.821.
  1747. .LP
  1748. [6]
  1749.      CCITT Recommendation \fICharacteristics of digital multiplex equipments\fR 
  1750. \fIbased on a second order bit rate of 6312\ kbit/s and using positive\fR 
  1751. \fIjustification\fR , Vol.\ III, Rec.\ G.752.
  1752. .LP
  1753. [7]
  1754.     CCITT Recommendation \fIFunctional characteristics of interfaces\fR 
  1755. \fIassociated with network nodes\fR , Vol.\ III, Rec.\ G.704.
  1756. .LP
  1757. [8]
  1758.     CCITT Recommendation \fICharacteristics of primary PCM multiplex\fR 
  1759. \fIequipment operating at 2048\ kbit/s\fR , Vol.\ III, Rec.\ G.732.
  1760. .LP
  1761. [9]
  1762.     CCITT Recommendation \fICharacteristics of primary PCM multiplex\fR 
  1763. \fIequipment operating at 1544\ kbit/s\fR , Vol.\ III, Rec.\ G.733.
  1764. \v'1P'
  1765. .sp 2P
  1766. .LP
  1767. \fBRecommendation\ M.21\fR 
  1768. .RT
  1769. .sp 2P
  1770. .ce 1000
  1771. \fBPRINCIPLES\ FOR\ MAINTENANCE\ PHILOSOPHY\ AND\ CONSIDERATIONS\fR 
  1772. .EF '%    Fascicle\ IV.1\ \(em\ Rec.\ M.21''
  1773. .OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.21    %'
  1774. .ce 0
  1775. .sp 1P
  1776. .ce 1000
  1777. \fBFOR\ MAINTENANCE\ STRATEGY\ FOR |
  1778. TELECOMMUNICATION\ SERVICES\fR 
  1779. .FS
  1780. It is intended that
  1781. the subject matters contained in this Recommendation
  1782. will be studied and developed further as the results of the
  1783. work done in other Study Groups on Quality of Service concepts
  1784. become available.
  1785. .FE
  1786. .ce 0
  1787. .sp 1P
  1788. .LP
  1789. \fB1\fR     \fBIntroduction\fR 
  1790. .sp 1P
  1791. .RT
  1792. .PP
  1793. The purpose of this Recommendation is to provide principles for a maintenance 
  1794. philosophy which can be applied to all telecommunication services, and 
  1795. from which a common strategy can be derived. 
  1796. .RT
  1797. .sp 2P
  1798. .LP
  1799. \fB2\fR     \fBQuality of Service\fR 
  1800. .sp 1P
  1801. .RT
  1802. .PP
  1803. An important concept in the consideration of a maintenance
  1804. philosophy is that of Quality of Service (QOS).
  1805. .PP
  1806. This is defined in Recommendation E.800 [1] as \*Qthe collective effect 
  1807. of service performances which determine the degree of satisfaction of a 
  1808. user 
  1809. service\*U.
  1810. .RT
  1811. .sp 2P
  1812. .LP
  1813. \fB3\fR     \fBQuality of Service factors\fR 
  1814. .sp 1P
  1815. .RT
  1816. .PP
  1817. QOS comprises a number of Quality of Service factors or
  1818. performances
  1819. which are enumerated and defined in Recommendation\ E.800\ [1] and listed 
  1820. below. Some of these comprise further factors. 
  1821. .PP
  1822. They are illustrated in Figure\ 1/M.21 which is taken from
  1823. Recommendation\ E.800\ [1].
  1824. .RT
  1825. .LP
  1826.     i)
  1827.     service support performance;
  1828. .LP
  1829.     ii)
  1830.     service operability performance;
  1831. .LP
  1832.     iii)
  1833.     serveability performance;
  1834. .LP
  1835.     iv)
  1836.     service accessibility performance;
  1837. .LP
  1838.     v)
  1839.     service retainability performance;
  1840. .LP
  1841.     vi)
  1842.     service integrity;
  1843. .LP
  1844.     vii)
  1845.     transmission performance;
  1846. .LP
  1847.     viii)
  1848.     trafficability performance;
  1849. .LP
  1850.     ix)
  1851.     propagation performance;
  1852. .LP
  1853.     x)
  1854.     availability (performance);
  1855. .LP
  1856.     xi)
  1857.     reliability (performance);
  1858. .LP
  1859.     xii)
  1860.     maintainability (performance);
  1861. .LP
  1862.     xiii)
  1863.     maintenance support (performance).
  1864. .bp
  1865. .LP
  1866. .rs
  1867. .sp 28P
  1868. .ad r
  1869. \fBFigure 1/M.21, p.\fR 
  1870. .sp 1P
  1871. .RT
  1872. .ad b
  1873. .RT
  1874. .sp 2P
  1875. .LP
  1876. \fB4\fR     \fBRelationship between Quality of Service factors which are
  1877. relevant in maintenance\fR 
  1878. .sp 1P
  1879. .RT
  1880. .PP
  1881. Figure 1/M.21 indicates the relationship between the availability performance 
  1882. of individual items (e.g.,\ terminal equipment, networks,\ etc.) 
  1883. which are used in the operation of a service and the serveability performance 
  1884. of that service. This relationship is such that, given satisfactory 
  1885. trafficability and propagation performances, then the availabiity performance 
  1886. of each item is the means by which satisfactory serveability of a service 
  1887. is 
  1888. obtained.
  1889. .RT
  1890. .sp 2P
  1891. .LP
  1892. \fB5\fR     \fBPrinciples of\fR 
  1893. \fBmaintenance philosophy for telecommunication\fR \fBservice\fR 
  1894. .sp 1P
  1895. .RT
  1896. .PP
  1897. 5.1
  1898. Serveability performance of a service should be completely and precisely 
  1899. defined, in terms of parameters to be taken into consideration and 
  1900. performance objectives, tolerances and conditions for these parameters.
  1901. .sp 9p
  1902. .RT
  1903. .PP
  1904. 5.2
  1905. Performance objectives of items used for services should be
  1906. considered with reference to the serveability performance of these services.
  1907. .PP
  1908. 5.3
  1909. In the case where an item is shared by services, then its
  1910. performance objectives should be such as to enable the service with the most
  1911. stringent serveability requirement to meet this, given that trafficability 
  1912. and propagation performance are satisfactory. 
  1913. .PP
  1914. 5.4
  1915. Maintenance arrangements for a service should be such that all
  1916. Quality of Service factors which are relevant to maintenance are satisfactory.
  1917. .PP
  1918. 5.5
  1919. As factors other than those of Quality of Service (maintenance and operation 
  1920. costs, durability of equipments,\ etc.) and a large variety of 
  1921. networks and services need to be taken into consideration when organizing
  1922. maintenance, arrangements for maintenance of a service should be defined 
  1923. as far as possible within a common and global approach. 
  1924. .bp
  1925. .sp 2P
  1926. .LP
  1927. \fB6\fR     \fBMaintenance considerations for new telecommunication\fR 
  1928. \fBservices\fR 
  1929. .sp 1P
  1930. .RT
  1931. .PP
  1932. 6.1
  1933. When a new service is to be introduced, early consideration
  1934. should be given to its operational and maintenance requirements. In practice, 
  1935. these will depend on its Quality of Service objectives and therefore on 
  1936. the 
  1937. performance parameter objectives which are set for each item which is used 
  1938. for operating the service (e.g.,\ terminal equipment, network,\ etc.). 
  1939. Thus each item should be considered individually. 
  1940. .sp 9p
  1941. .RT
  1942. .PP
  1943. 6.2
  1944. If such an item is unique to a service, there will be new
  1945. operational and maintenance requirements.
  1946. .PP
  1947. 6.3
  1948. If such an item is not unique to a service and it is already used in providing 
  1949. an existing service, then consideration should be given to whether the 
  1950. existing operational and maintenance requirements need to be changed. This 
  1951. will depend on whether the performance parameter objectives are changed. 
  1952. .PP
  1953. 6.4
  1954. Operational and maintenance requirements should address the
  1955. following areas:
  1956. .LP
  1957.     \(em
  1958.     line\(hyup and provisioning procedures;
  1959. .LP
  1960.     \(em
  1961.     maintenance procedures, including those for fault prevention,
  1962. detection, reporting and localization;
  1963. .LP
  1964.     \(em
  1965.     restoration procedures;
  1966. .LP
  1967.     \(em
  1968.     restoration requirements (e.g., maximum permitted number of
  1969. restoration links in tandem, maximum permitted propagation
  1970. delay, maximum tolerable interruption duration, degree of
  1971. protection required);
  1972. .LP
  1973.     \(em
  1974.     serveability performance;
  1975. .LP
  1976.     \(em
  1977.     organization of operation and maintenance effort to deal
  1978. with the above\(hymentioned areas;
  1979. .LP
  1980.     \(em
  1981.     the interaction required between elements and centres of
  1982. operation and maintenance effort;
  1983. .LP
  1984.     \(em
  1985.     testing equipment and facilities for use within the
  1986. operation and maintenance organization;
  1987. .LP
  1988.     \(em
  1989.     the exchange of contact point information (as indicated in
  1990. Recommendation\ M.93);
  1991. .LP
  1992.     \(em
  1993.     maintenance limits for transmission performance
  1994. parameters.
  1995. .PP
  1996. 6.5
  1997. Consideration should also be given to whether, in the provision and maintenance 
  1998. of a service, these subject areas require inter\(hyadministration agreements 
  1999. or the development of specific CCITT Recommendations. 
  2000. .sp 9p
  2001. .RT
  2002. .sp 2P
  2003. .LP
  2004.     \fBReferences\fR 
  2005. .sp 1P
  2006. .RT
  2007. .LP
  2008. [1]
  2009.     CCITT Recommendation \fIQuality of Service and dependability\fR 
  2010. \fIvocabulary\fR , Vol.\ II, Rec.\ E.800.
  2011. \v'1P'
  2012. .sp 2P
  2013. .LP
  2014.  |
  2015. \fBRecommendation\ M.30\fR 
  2016. .RT
  2017. .sp 2P
  2018. .sp 1P
  2019. .ce 1000
  2020. \fBPRINCIPLES\ FOR\ A\ TELECOMMUNICATIONS\ MANAGEMENT\ NETWORK\fR 
  2021. .EF '%    Fascicle\ IV.1\ \(em\ Rec.\ M.30''
  2022. .OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.30    %'
  2023. .ce 0
  2024. .sp 1P
  2025. .LP
  2026. \fB1\fR     \fBGeneral\fR 
  2027. .sp 1P
  2028. .RT
  2029. .PP
  2030. This Recommendation presents the general principles for planning, operating 
  2031. and maintaining a Telecommunications Management Network (TMN). The purpose 
  2032. of a TMN is to support Administrations in management of its 
  2033. telecommunications network. A TMN provides a host of management functions to
  2034. the telecommunication network and offers communications between itself 
  2035. and the telecommunication network. In this context a telecommunications 
  2036. network is 
  2037. assumed to consist of both digital and analogue telecommunications equipment
  2038. and associated support equipment.
  2039. .bp
  2040. .PP
  2041. The basic concept behind a TMN, therefore, is to provide an organized network 
  2042. structure to achieve the interconnection of the various types of 
  2043. Operations Systems (OSs) and telecommunications equipment using an agreed
  2044. upon architecture with standardized protocols and interfaces. This will 
  2045. provide the telecommunication network Administrations and telecommunication 
  2046. equipment manufacturers a set of standards to use when developing equipment 
  2047. for and 
  2048. designing a management network for modern telecommunication networks [including 
  2049. their Integrated Services Digital Networks (ISDNs)]. 
  2050. .RT
  2051. .sp 1P
  2052. .LP
  2053. 1.1
  2054.     \fIRelationships of a TMN to a telecommunication network\fR 
  2055. .sp 9p
  2056. .RT
  2057. .PP
  2058. A TMN can vary in size from a very simple connection between an OS and 
  2059. a single piece of telecommunication equipment to a massive network 
  2060. interconnecting many different types of OSs and telecommunication equipment. 
  2061. It may provide a host of management functions and offers communications 
  2062. both 
  2063. between the OSs and between OSs and the various parts of the telecommunication 
  2064. network which consists of many types of digital and analogue telecommunication 
  2065. equipment and associated support equipment, such as transmission systems, 
  2066. switching systems, multiplexers, signalling terminals. Such equipment is
  2067. referred to generically as network elements (NEs).
  2068. .PP
  2069. Figure 1/M.30 shows the general relationship between a TMN and a
  2070. telecommunications network which it manages. Note that a TMN is conceptually 
  2071. a separate network that interfaces a telecommunications network at several 
  2072. different points to receive information from it and to control its operations. 
  2073. However, a TMN may often use parts of the telecommunication network to 
  2074. provide its communications. 
  2075. .RT
  2076. .LP
  2077. .rs
  2078. .sp 32P
  2079. .ad r
  2080. \fBFigure 1/M.30, p.\fR 
  2081. .sp 1P
  2082. .RT
  2083. .ad b
  2084. .RT
  2085. .LP
  2086. .bp
  2087. .sp 1P
  2088. .LP
  2089. 1.2
  2090.     \fIField of application\fR 
  2091. .sp 9p
  2092. .RT
  2093. .PP
  2094. The following are examples of the networks and major types of
  2095. equipment that may be managed over the TMN:
  2096. .RT
  2097. .LP
  2098.     \(em
  2099.     public and private networks, including ISDNs;
  2100. .LP
  2101.     \(em
  2102.     transmission terminals (multiplexers, cross connects,
  2103. channel translation equipment, etc.);
  2104. .LP
  2105.     \(em
  2106.     digital and analogue transmission systems (cable, fibre,
  2107. radio, satellite, etc.);
  2108. .LP
  2109.     \(em
  2110.     restoration systems;
  2111. .LP
  2112.     \(em
  2113.     digital and analogue exchanges;
  2114. .LP
  2115.     \(em
  2116.     circuit and packet switched networks;
  2117. .LP
  2118.     \(em
  2119.     signalling terminal and systems including signal transfer
  2120. points (STP) and real time data bases;
  2121. .LP
  2122.     \(em
  2123.     PBXs and customer terminals;
  2124. .LP
  2125.     \(em
  2126.     ISDN user terminals;
  2127. .LP
  2128.     \(em
  2129.      associated support systems (test modules, power systems, air conditioning 
  2130. units, building alarms systems, etc.). 
  2131. .PP
  2132. In addition, by the monitoring, testing or control of these
  2133. equipments, a TMN may be used to manage distributed entities such as circuits.
  2134. .sp 2P
  2135. .LP
  2136. \fB2\fR     \fBTMN architecture and definitions\fR 
  2137. .sp 1P
  2138. .RT
  2139. .PP
  2140. The following definitions for the TMN architecture are conceptual in nature 
  2141. and are thus intended to be working definitions that cover the most common 
  2142. and general cases. It should be recognized that, because of the 
  2143. exceedingly complex nature of some telecommunications equipment and because 
  2144. of the ability, using microprocessors, to distribute functionality within 
  2145. various network parts, these definitions may not rigidly cover every possible 
  2146. physical configuration that may be encountered. However, even these exceptions 
  2147. are 
  2148. expected to fit within the general TMN concept and to be covered by its
  2149. principles.
  2150. .RT
  2151. .sp 1P
  2152. .LP
  2153. 2.1
  2154.     \fITMN functional architecture\fR 
  2155. .sp 9p
  2156. .RT
  2157. .PP
  2158. A TMN functionally provides the means to transport and process
  2159. information related to the management of telecommunication networks. As 
  2160. shown in Figure\ 2/M.30, it is made up of operations system functions (OSFs), 
  2161. mediation functions (MFs) and data communications functions (DCFs). The
  2162. function blocks provide the TMN general functions which enable a TMN to 
  2163. perform the TMN application functions. A TMN is also connected to network 
  2164. element 
  2165. functions (NEFs) and workstation functions (WSFs).
  2166. .PP
  2167. Figure 2/M.30 shows the 
  2168. function blocks of a TMN
  2169. . As shown,
  2170. all like reference points (q\ to\ q, f\ to\ f, and x\ to\ x) are connected 
  2171. through 
  2172. the facility of the DCF. The WSF may also be directly connected to the NEF
  2173. through a connection external to the TMN.
  2174. .RT
  2175. .sp 2P
  2176. .LP
  2177. 2.1.1
  2178.     \fIDefinition of function blocks\fR 
  2179. .sp 1P
  2180. .RT
  2181. .sp 1P
  2182. .LP
  2183. 2.1.1.1
  2184.     \fBoperations system function (OSF) block\fR 
  2185. .sp 9p
  2186. .RT
  2187. .PP
  2188. The OSF block processes information related to telecommunication management 
  2189. to support and/or control the realization of various 
  2190. telecommunication management functions. Details of the OSF are given
  2191. in\ \(sc\ 5.2.
  2192. .RT
  2193. .sp 1P
  2194. .LP
  2195. 2.1.1.2
  2196.     \fBmediation function (MF) block\fR 
  2197. .sp 9p
  2198. .RT
  2199. .PP
  2200. The MF block acts on information passing between NEFs and OSFs to achieve 
  2201. smooth and efficient communication. Major MFs include communication 
  2202. control, protocol conversion and data handling, communication of primitive
  2203. functions, processes involving decision making, and data storage. Details of
  2204. the MF are given in\ \(sc\ 5.4.
  2205. .RT
  2206. .sp 1P
  2207. .LP
  2208. 2.1.1.3
  2209.     \fBdata communications function (DCF) block\fR 
  2210. .sp 9p
  2211. .RT
  2212. .PP
  2213. The DCF block provides the means for data communication to
  2214. transport information related to telecommunications management between 
  2215. function blocks. Details of the CDF are given in\ \(sc\ 5.3. 
  2216. .bp
  2217. .RT
  2218. .LP
  2219. .rs
  2220. .sp 37P
  2221. .ad r
  2222. \fBFigure 2/M.30, p.\fR 
  2223. .sp 1P
  2224. .RT
  2225. .ad b
  2226. .RT
  2227. .sp 1P
  2228. .LP
  2229. 2.1.1.4
  2230.     \fBnetwork element function (NEF) block\fR 
  2231. .sp 9p
  2232. .RT
  2233. .PP
  2234. The NEF block communicates with a TMN for the purpose of being
  2235. monitored and/or controlled. Details of the NEF are given in\ \(sc\ 5.5.
  2236. .RT
  2237. .sp 1P
  2238. .LP
  2239. 2.1.1.5
  2240.     \fBwork station function (WSF) block\fR 
  2241. .sp 9p
  2242. .RT
  2243. .PP
  2244. The WSF block provides means for communications among function
  2245. blocks (OSF, MF, DCF, NEF) and the user. Details of the WSF are given
  2246. in\ \(sc\ 5.6.
  2247. .RT
  2248. .sp 1P
  2249. .LP
  2250. 2.1.2
  2251.     \fIDefinitions of reference points\fR 
  2252. .sp 9p
  2253. .RT
  2254. .PP
  2255. The following reference points define conceptual points of
  2256. information exchange between non\(hyoverlapping function blocks. A reference 
  2257. point becomes an interface when the connected function blocks are embodied 
  2258. in 
  2259. separate pieces of equipment.
  2260. .bp
  2261. .RT
  2262. .sp 1P
  2263. .LP
  2264. 2.1.2.1
  2265.     \fBq reference points\fR 
  2266. .sp 9p
  2267. .RT
  2268. .PP
  2269. The q reference points connect the function blocks NEF to MF, MF to MF, 
  2270. MF to OSF and OSF to OSF either directly or via the DCF. Within the class 
  2271. of q reference points the following distinctions are made: 
  2272. .RT
  2273. .LP
  2274.     q\d1\u:
  2275.     the q\d1\ureference points connect NEF to MF either
  2276. directly or via the DCF;
  2277. .LP
  2278.     q\d2\u:
  2279.     the q\d2\ureference points connect MF to MF either
  2280. directly or via the DCF;
  2281. .LP
  2282.     q\d3\u:
  2283.      the q\d3\ureference points connect MF to OSF and OSF to OSF either directly 
  2284. or via the DCF. 
  2285. .sp 1P
  2286. .LP
  2287. 2.1.2.2
  2288.     \fBf reference points\fR 
  2289. .sp 9p
  2290. .RT
  2291. .PP
  2292. The f reference points connect function blocks OSF, MF, NEF, DCF to the WSF.
  2293. .RT
  2294. .sp 1P
  2295. .LP
  2296. 2.1.2.3
  2297.     \fBg reference points\fR 
  2298. .sp 9p
  2299. .RT
  2300. .PP
  2301. The g reference points are points between the WSF and the
  2302. user.
  2303. .RT
  2304. .sp 1P
  2305. .LP
  2306. 2.1.2.4
  2307.     \fBx reference points\fR 
  2308. .sp 9p
  2309. .RT
  2310. .PP
  2311. The x reference points connect a TMN to other management type
  2312. networks including other TMNs.
  2313. .RT
  2314. .sp 1P
  2315. .LP
  2316. 2.2
  2317.     \fITMN physical architecture\fR 
  2318. .sp 9p
  2319. .RT
  2320. .PP
  2321. Figure 3/M.30 shows a generalized physical architecture for the
  2322. TMN.
  2323. .RT
  2324. .sp 1P
  2325. .LP
  2326. 2.2.1
  2327.     \fIDefinitions of the physical architecture\fR 
  2328. .sp 9p
  2329. .RT
  2330. .PP
  2331. TMN functions can be implemented in a variety of physical
  2332. configurations. The following are the definitions for consideration of
  2333. implementation schemes.
  2334. .RT
  2335. .sp 1P
  2336. .LP
  2337. 2.2.1.1
  2338.     \fBoperations system (OS)\fR 
  2339. .sp 9p
  2340. .RT
  2341. .PP
  2342. The OS is the stand alone system which performs OSFs.
  2343. .RT
  2344. .sp 1P
  2345. .LP
  2346. 2.2.1.2
  2347.     \fBmediation device (MD)\fR 
  2348. .sp 9p
  2349. .RT
  2350. .PP
  2351. The MD is the stand alone device which performs MFs. MDs can be
  2352. implemented as hierarchies of cascaded devices.
  2353. .RT
  2354. .sp 1P
  2355. .LP
  2356. 2.2.1.3
  2357.     \fBdata communications network\fR 
  2358. .sp 9p
  2359. .RT
  2360. .PP
  2361. The DCN is a communication network within a TMN which supports the DCF 
  2362. at the reference point q\d3\u. 
  2363. .RT
  2364. .sp 1P
  2365. .LP
  2366. 2.2.1.4
  2367.     \fBlocal communication network (LCN)\fR 
  2368. .sp 9p
  2369. .RT
  2370. .PP
  2371. The LCN is a communication network within a TMN which supports the DCF 
  2372. normally at the reference points q\d1\uand q\d2\u. 
  2373. .RT
  2374. .sp 1P
  2375. .LP
  2376. 2.2.1.5
  2377.     \fBnetwork element (NE)\fR 
  2378. .sp 9p
  2379. .RT
  2380. .PP
  2381. The NE is comprised of telecommunication equipment (or groups/parts of 
  2382. telecommunication equipment) and support equipment that performs NEFs and 
  2383. has one or more standard Q\(hytype interfaces.
  2384. .RT
  2385. .sp 1P
  2386. .LP
  2387. 2.2.1.6
  2388.     \fBworkstation (WS)\fR 
  2389. .sp 9p
  2390. .RT
  2391. .PP
  2392. The WS is the stand alone system which performs WSFs.
  2393. .bp
  2394. .RT
  2395. .LP
  2396. .rs
  2397. .sp 35P
  2398. .ad r
  2399. \fBFigure 3/M.30, p.\fR 
  2400. .sp 1P
  2401. .RT
  2402. .ad b
  2403. .RT
  2404. .sp 1P
  2405. .LP
  2406. 2.2.2
  2407.     \fIDefinitions of the standard interfaces\fR 
  2408. .sp 9p
  2409. .RT
  2410. .PP
  2411. Standard interfaces are defined corresponding to the reference
  2412. points.
  2413. .RT
  2414. .sp 1P
  2415. .LP
  2416. 2.2.2.1
  2417.     \fBQ interface\fR 
  2418. .sp 9p
  2419. .RT
  2420. .PP
  2421. The Q interface is applied at q reference points. To provide
  2422. flexibility of implementation, the class of Q interfaces is made up of the
  2423. following three subclasses:
  2424. .RT
  2425. .LP
  2426.     \(em
  2427.      interface Q\d1\u, intended to connect NEs containing no MF to MDs or 
  2428. to NEs containing MF via an LCN 
  2429. .LP
  2430.     \(em
  2431.     interface Q\d2\u, intended to connect MDs to MDs, NEs
  2432. containing MF to MDs or to other NEs containing MF via an LCN
  2433. .LP
  2434.     \(em
  2435.      interface Q\d3\u, intended to connect MDs, NEs containing MF and OSs 
  2436. to OSs via a DCN. 
  2437. .PP
  2438. \fINote\ 1\fR \ \(em\ Applications different from primary applications are
  2439. not excluded when different functions are combined for implementation.
  2440. .PP
  2441. \fINote\ 2\fR \ \(em\ A higher numbered interface will generally use a more
  2442. sophisticated protocol than a lower numbered interface.
  2443. .bp
  2444. .RT
  2445. .sp 1P
  2446. .LP
  2447. 2.2.2.2
  2448.     \fBF interface\fR 
  2449. .sp 9p
  2450. .RT
  2451. .PP
  2452. The F interface is applied at f reference points.
  2453. .RT
  2454. .sp 1P
  2455. .LP
  2456. 2.2.2.3
  2457.     \fBG interface\fR 
  2458. .sp 9p
  2459. .RT
  2460. .PP
  2461. The G interface is applied at the g reference point.
  2462. .RT
  2463. .sp 1P
  2464. .LP
  2465. 2.2.2.4
  2466.     \fBX interface\fR 
  2467. .sp 9p
  2468. .RT
  2469. .PP
  2470. The X interface is applied at the x reference point.
  2471. .RT
  2472. .sp 1P
  2473. .LP
  2474. 2.3
  2475.     \fITMN protocol families\fR 
  2476. .sp 9p
  2477. .RT
  2478. .PP
  2479. The Q interfaces as present on the DCN and the LCN determine
  2480. protocol families PQ\dD\u\dC\\dN\uand PQ\dL\\dC\\dN\u.
  2481. .RT
  2482. .sp 2P
  2483. .LP
  2484. 2.3.1
  2485.     \fIDefinitions of the TMN protocol families\fR 
  2486. .sp 1P
  2487. .RT
  2488. .sp 1P
  2489. .LP
  2490. 2.3.1.1
  2491.     \fBPQ\fR\(da\fBD\fR\(da\fBC\fR\(da\fBN\fR 
  2492. .sp 9p
  2493. .RT
  2494. .PP
  2495. A family of protocol suites for use with the DCN applied to the
  2496. Q\d3\uinterface.
  2497. .RT
  2498. .sp 1P
  2499. .LP
  2500. 2.3.1.2
  2501.     \fBPQ\fR\(da\fBL\fR\(da\fBC\fR\(da\fBN\fR 
  2502. .sp 9p
  2503. .RT
  2504. .PP
  2505. A family of protocol suites for use with the LCN, applied to the
  2506. Q\d1\uand Q\d2\uinterfaces.
  2507. .RT
  2508. .sp 2P
  2509. .LP
  2510. 2.4
  2511.     \fIConsideration of reference and physical configurations\fR 
  2512. .sp 1P
  2513. .RT
  2514. .sp 1P
  2515. .LP
  2516. 2.4.1
  2517.     \fIq\(hyclass considerations\fR 
  2518. .sp 9p
  2519. .RT
  2520. .sp 1P
  2521. .LP
  2522. 2.4.1.1
  2523.     \fIq\(hyclass reference configuration\fR 
  2524. .sp 9p
  2525. .RT
  2526. .PP
  2527. Figure 4/M.30 shows the q\(hyclass reference configuration
  2528. illustrating the q\d1\u, q\d2\uand q\d3\ureference points and the types of
  2529. functional blocks that can be connected to the reference points. Figure\ 
  2530. 4a/M.30 shows the case with explicit DCF (with data communication functions 
  2531. indicated). Since the DCF process preserves the information content, the 
  2532. same reference 
  2533. point appears on both sides of a DCF in the figure.
  2534. .RT
  2535. .sp 1P
  2536. .LP
  2537. 2.4.1.2
  2538.     \fIPhysical realization of the\fR 
  2539. \fIreference configuration\fR 
  2540. .sp 9p
  2541. .RT
  2542. .PP
  2543. Figure 5/M.30 shows examples of the relationship of the physical
  2544. configurations to the reference configuration with DCFs not explicitly shown
  2545. (implicit DCF case). It illustrates combinations of physical interfaces 
  2546. at the reference points q\d1\u, q\d2\uand q\d3\u. At reference points where 
  2547. a physical interface appears, this is denoted with a capital\ Q. 
  2548. .PP
  2549. Figure 5/M.30, case a), shows an NE physically connected via a Q\d1\uinterface 
  2550. to an MD, two MDs interconnected with a Q\d2\uinterface and the top MD 
  2551. connected with OS via the Q\d3\uinterface. 
  2552. .PP
  2553. Figure 5/M.30, case b), shows an NE physically connected to an MD via a 
  2554. Q\d1\uinterface. The MFs are merged into one MD which interfaces to the 
  2555. OS 
  2556. via a Q\d3\uinterface, (see also Note\ 1).
  2557. .PP
  2558. Figure 5/M.30, case c), shows an NE with an internal MF which is
  2559. interconnected to an MD via a Q\d2\uinterface. The MD is connected to the OS
  2560. via a Q\d3\uinterface.
  2561. .PP
  2562. Figure 5/M.30, case d), shows an NE with MFs directly connected to the 
  2563. OS via a Q\d3\uinterface. 
  2564. .bp
  2565. .PP
  2566. \fINote\ 1\fR \ \(em\ Where a reference point is shown in Figure\ 5/M.30 this
  2567. means that the point is inside a physical box. The designer is free to apply
  2568. any implementation. It is not necessary that this point is physically present 
  2569. inside the equipment. 
  2570. .PP
  2571. \fINote\ 2\fR \ \(em\ Any other equipment may be present between two adjacent
  2572. boxes, which is necessary for the connection of these boxes. This equipment
  2573. represents the DCF of Figure\ 2/M.30. Such equipments perform OSI network
  2574. functions and are not shown in Figure\ 5/M.30, e.g., the Q\d3\uinterface
  2575. normally connects to the DCN which provides the data communication to the
  2576. OS.
  2577. .RT
  2578. .LP
  2579. .rs
  2580. .sp 37P
  2581. .ad r
  2582. \fBFigure 4/M.30, p. 12\fR 
  2583. .sp 1P
  2584. .RT
  2585. .ad b
  2586. .RT
  2587. .PP
  2588. Figure 6/M.30 shows the same examples of the relationship of the physical 
  2589. configuration to the reference configuration as those given in 
  2590. Figure\ 5/M.30, but with the DCFs explicitly shown (explicit DCF case). 
  2591. It also shows different possible configurations that may be used for an 
  2592. LCN (e.g.\ star, bus or ring). 
  2593. .bp
  2594. .LP
  2595. .rs
  2596. .sp 47P
  2597. .ad r
  2598. \fBFigure 5/M.30, p.\fR 
  2599. .sp 1P
  2600. .RT
  2601. .ad b
  2602. .RT
  2603. .LP
  2604. .bp
  2605. .LP
  2606. .rs
  2607. .sp 47P
  2608. .ad r
  2609. \fBFigure 6/M.30, p.\fR 
  2610. .sp 1P
  2611. .RT
  2612. .ad b
  2613. .RT
  2614. .LP
  2615. .bp
  2616. .PP
  2617. Figure 7/M.30 shows examples, with the DCFs not explicitly shown, of a 
  2618. special group of physical configurations in which NEs are cascaded to 
  2619. provide a single interface to the higher order TMN equipment. This is
  2620. convenient for co\(hylocated NEs which generally contain different levels 
  2621. of MF, e.g., transmission equipment co\(hylocated with an exchange. 
  2622. .PP
  2623. Figure 7/M.30 case a), shows how an NE without an internal MF is
  2624. connected via a Q\d1\uinterface to an NE with an internal MF which itself 
  2625. has a Q\d2\uinterface to an MD. 
  2626. .PP
  2627. Figure 7/M.30 case b), shows how an NE with an internal MF is
  2628. connected via a Q\d2\uinterface to an NE with higher level MF, which itself 
  2629. has a Q\d3\uinterface to OS. 
  2630. .PP
  2631. Figure 7/M.30 case c), shows another possibility where an NE without an 
  2632. internal MF has a Q\d1\uinterface to an NE with an internal MF which itself 
  2633. has a Q\d3\uinterface to OS. 
  2634. .RT
  2635. .PP
  2636. Figure 8/M.30 shows simplified examples of how NEs and MDs might be physically 
  2637. cascaded to serve multiple NEs. The examples show the connections to the 
  2638. OSs, but do not explicitly show the connections to the DCFs. 
  2639. .sp 2P
  2640. .LP
  2641. \fB3\fR     \fBFunctions associated with a TMN\fR 
  2642. .sp 1P
  2643. .RT
  2644. .PP
  2645. The functions associated with a TMN can be split into two
  2646. parts:
  2647. .RT
  2648. .LP
  2649.     \(em
  2650.      TMN general functions provided by the function blocks defined in\ \(sc\ 
  2651. 2.1; and 
  2652. .LP
  2653.     \(em
  2654.     TMN application functions listed in\ \(sc\ 3.2;
  2655. .sp 1P
  2656. .LP
  2657. 3.1
  2658.     \fITMN general functions\fR 
  2659. .sp 9p
  2660. .RT
  2661. .PP
  2662. The TMN general functions provide support for the TMN application functions. 
  2663. Examples of TMN general functions are: 
  2664. .RT
  2665. .LP
  2666.     \(em
  2667.     transport, which provides for the movement of information
  2668. among TMN elements;
  2669. .LP
  2670.     \(em
  2671.     storage, which provides for holding information over
  2672. controlled amounts of time;
  2673. .LP
  2674.     \(em
  2675.      security, which provides control over access for reading or changing 
  2676. information; 
  2677. .LP
  2678.     \(em
  2679.     retrieval, which provides access to information;
  2680. .LP
  2681.     \(em
  2682.     processing, which provides for analysis and information
  2683. manipulation;
  2684. .LP
  2685.     \(em
  2686.     user terminal support which, provides for input/output of
  2687. information.
  2688. .sp 1P
  2689. .LP
  2690. 3.2
  2691.     \fITMN applications functions\fR 
  2692. .sp 9p
  2693. .RT
  2694. .PP
  2695. A TMN is intended to support a wide variety of application
  2696. functions which cover the operations, administration, maintenance and
  2697. provisioning of a telecommunication network.
  2698. .PP
  2699. These four categories have a different meaning depending on the
  2700. organization of an Administration. Moreover, some of the information which 
  2701. is exchanged over the TMN may be used in support of more than one management 
  2702. category. Therefore, the classification of the information exchange within 
  2703. the TMN is independent of the use that will be made of the information. 
  2704. .PP
  2705. While it cannot claim to be complete, this section describes some of the 
  2706. most important application functions in terms of the OSI management 
  2707. categories, expanded to fit the need of a TMN.
  2708. .PP
  2709. The application functions have been classified in accordance with
  2710. fields of use into major management categories:
  2711. .RT
  2712. .LP
  2713.     a)
  2714.     performance management,
  2715. .LP
  2716.     b)
  2717.     fault (or maintenance) management,
  2718. .LP
  2719.     c)
  2720.     configuration management,
  2721. .LP
  2722.     d)
  2723.     accounting management,
  2724. .LP
  2725.     e)
  2726.     security management.
  2727. .PP
  2728. These allocations are provisional and subject to future review and rearrangement. 
  2729. .PP
  2730. It should be noted that the functional configuration of the TMN will change 
  2731. depending on the phases in the life cycle and the momentary status of 
  2732. the related telecommunications equipment. Typical examples can be found 
  2733. in the development of installation functions and testing functions, notably 
  2734. when 
  2735. utilizing movable support equipment.
  2736. .bp
  2737. .RT
  2738. .LP
  2739. .rs
  2740. .sp 27P
  2741. .ad r
  2742. \fBFigure 7/M.30, p.\fR 
  2743. .sp 1P
  2744. .RT
  2745. .ad b
  2746. .RT
  2747. .LP
  2748. .rs
  2749. .sp 23P
  2750. .ad r
  2751. \fBFigure 8/M.30, p.\fR 
  2752. .sp 1P
  2753. .RT
  2754. .ad b
  2755. .RT
  2756. .LP
  2757. .bp
  2758. .sp 1P
  2759. .LP
  2760. 3.2.1
  2761.     \fIPerformance management\fR 
  2762. .sp 9p
  2763. .RT
  2764. .PP
  2765. Performance management provides functions to evaluate and report
  2766. upon the behaviour of telecom equipment and the effectiveness of the network 
  2767. or network element. Its role is to gather statistical data for the purpose 
  2768. of 
  2769. monitoring and correcting the behaviour and effectiveness of the network,
  2770. network element or equipment and to aid in planning and analysis. As such, 
  2771. it is carrying out the performance measuring phase of Recommendation\ M.20. 
  2772. .PP
  2773. The following functionalities have been defined:
  2774. .RT
  2775. .sp 1P
  2776. .LP
  2777. 3.2.1.1
  2778.     \fIPerformance monitoring functions\fR 
  2779. .sp 9p
  2780. .RT
  2781. .PP
  2782. Performance monitoring involves the continuous collection of data concerning 
  2783. the performance of the NE. While acute fault conditions will be 
  2784. detected by alarm surveillance methods, very low rate or intermittent error
  2785. conditions in multiple equipment units may interact resulting in poor service 
  2786. quality. Performance monitoring is designed to measure the overall quality 
  2787. on the monitored parameters in order to detect such deterioration. It may 
  2788. also be designed to detect characteristic patterns before signal quality 
  2789. has dropped 
  2790. below an acceptable level.
  2791. .RT
  2792. .sp 1P
  2793. .LP
  2794. 3.2.1.2
  2795.     \fITraffic management and network management functions\fR 
  2796. .sp 9p
  2797. .RT
  2798. .PP
  2799. A TMN collects traffic data from NEs and sends commands to NEs to reconfigure 
  2800. the telecommunication network or modify its operation to adjust to extraordinary 
  2801. traffic. 
  2802. .PP
  2803. A TMN may request traffic data reports to be sent from NEs, or such a report 
  2804. may be sent upon threshold triggering, or periodically, or on demand. At 
  2805. any time the TMN may modify the current set of thresholds and/or periods 
  2806. in the network. 
  2807. .PP
  2808. Reports from the NE may consist of raw data which is processed in a
  2809. TMN, or the NE may be capable of carrying out analysis of the data before 
  2810. the report is sent. 
  2811. .RT
  2812. .sp 1P
  2813. .LP
  2814. 3.2.1.3
  2815.     \fIQuality of Service (QOS) observation functions\fR 
  2816. .sp 9p
  2817. .RT
  2818. .PP
  2819. A TMN collects QOS data from NEs and supports the improvements in QOS. 
  2820. The TMN may request QOS data reports to be sent from the NE, or such a 
  2821. report may be sent automatically on a scheduled or threshold basis. At any
  2822. time, the TMN may modify the current schedule and/or thresholds. Reports 
  2823. from the NE on QOS data may consist of raw data which is processed in a 
  2824. TMN, or the NE may be capable of carrying out analysis of the data before 
  2825. the report is 
  2826. sent.
  2827. .PP
  2828. Quality of Service includes monitoring and recording of parameters
  2829. relating to;
  2830. .RT
  2831. .LP
  2832.     \(em
  2833.      connection establishment (e.g.\ call set up delays, successful and failed 
  2834. call requests); 
  2835. .LP
  2836.     \(em
  2837.     connection retention;
  2838. .LP
  2839.     \(em
  2840.     connection quality;
  2841. .LP
  2842.     \(em
  2843.     billing integrity;
  2844. .LP
  2845.     \(em
  2846.     keeping and examining of logs of system state histories;
  2847. .LP
  2848.     \(em
  2849.     cooperation with fault (or maintenance) management to
  2850. establish possible failure of a resource and with configuration management 
  2851. to change routing and load control parameters/limits for links\ etc.; 
  2852. .LP
  2853.     \(em
  2854.     initiation of test calls to monitor QOS parameters.
  2855. .sp 1P
  2856. .LP
  2857. 3.2.2
  2858.     \fIFault (or maintenance) management\fR 
  2859. .sp 9p
  2860. .RT
  2861. .PP
  2862. Fault (or maintenance) management is a set of functions which
  2863. enables the detection, isolation and correction of abnormal operation of the
  2864. telecommunication network and its environment. It provides facilities for 
  2865. the performance of the following maintenance phases from 
  2866. Recomendation\ M.20,\ \(sc\ 5.
  2867. .RT
  2868. .sp 1P
  2869. .LP
  2870. 3.2.2.1
  2871.     \fIAlarm surveillance functions\fR 
  2872. .sp 9p
  2873. .RT
  2874. .PP
  2875. A TMN provides the capability to monitor NE failures in near real time. 
  2876. When such a failure occurs, an indication is made available by the NE. 
  2877. Based on this, a TMN determines the nature and severity of the fault. For
  2878. example, it may determine the effect
  2879. .bp
  2880. .PP
  2881. of the fault on the services
  2882. supported by
  2883. the faulty equipment. This can be accomplished in either of two ways: a data
  2884. base within a TMN may serve to interpret binary alarm indications from 
  2885. the NE, or if the NE has sufficient intelligence, it may transmit self\(hyexplanatory 
  2886. messages to a TMN. The first method requires little of the NE beyond a basic
  2887. self\(hymonitoring capability. The second method requires additionally 
  2888. that both the NE and a TMN support some type of message syntax which will 
  2889. allow adequate description of fault conditions. 
  2890. .RT
  2891. .sp 1P
  2892. .LP
  2893. 3.2.2.2
  2894.     \fIFault localization functions\fR 
  2895. .sp 9p
  2896. .RT
  2897. .PP
  2898. Where the initial failure information is insufficient for fault
  2899. localization it has to be augmented with information obtained by additional
  2900. failure localization routines. The routines can employ internal or external
  2901. test systems and can be controlled by a TMN (see Recommendation\ M.20).
  2902. .RT
  2903. .sp 1P
  2904. .LP
  2905. 3.2.2.3
  2906.     \fITesting functions\fR \fI(requested, on demand, or as\fR 
  2907. \fIa routine test)\fR 
  2908. .sp 9p
  2909. .RT
  2910. .PP
  2911. Testing can be carried out in one of two ways. In one case, a TMN directs 
  2912. a given NE to carry out analysis of circuit or equipment 
  2913. characteristics. Processing is executed entirely within the NE and the 
  2914. results are automatically reported to the TMN, either immediately or on 
  2915. a delayed 
  2916. basis.
  2917. .PP
  2918. Another method is where the analysis is carried out within the TMN. In 
  2919. this case, the TMN merely requests that the NE provide access to the circuit 
  2920. or equipment of interest and no other messages are exchanged with the NE.
  2921. .RT
  2922. .sp 1P
  2923. .LP
  2924. 3.2.3
  2925.     \fIConfiguration management\fR 
  2926. .sp 9p
  2927. .RT
  2928. .PP
  2929. Configuration management provides functions to exercise control
  2930. over, identify, collect data from and provide data to NEs.
  2931. .RT
  2932. .sp 1P
  2933. .LP
  2934. 3.2.3.1
  2935.     \fIProvisioning functions\fR 
  2936. .sp 9p
  2937. .RT
  2938. .PP
  2939. Provisioning consists of procedures which are necessary to bring an equipment 
  2940. into service, not including installation. Once the unit is ready for service, 
  2941. the supporting programmes are initialized via the TMN. The state of 
  2942. the unit, e.g., in service, out of service, stand\(hyby, reserved, and selected
  2943. parameters may also be controlled by provisioning functions.
  2944. .PP
  2945. Over the spectrum of network elements, the use of the provisioning
  2946. functions can vary widely. For small transmission elements, these functions 
  2947. are used once and rarely again. Digital switching and cross\(hyconnect 
  2948. equipment may require frequent use of these functions as circuits are put 
  2949. up and 
  2950. dropped.
  2951. .RT
  2952. .sp 1P
  2953. .LP
  2954. 3.2.3.2
  2955.     \fIStatus and control functions\fR 
  2956. .sp 9p
  2957. .RT
  2958. .PP
  2959. The TMN provides the capability to monitor and control certain
  2960. aspects of the NE on demand. Examples include checking or changing the 
  2961. service state of an NE or one of its sub\(hyparts (in service, out of service, 
  2962. stand\(hyby) and initiating diagnostics tests within the NE. Normally, 
  2963. a status check is 
  2964. provided in conjunction with each control function in order to verify that 
  2965. the resulting action has taken place. When associated with failure conditions, 
  2966. these functions are corrective in nature (e.g., service restoral).
  2967. .PP
  2968. Status and control functions can also be part of routine maintenance when 
  2969. executed automatically or on a scheduled periodic basis. An example is 
  2970. switching a channel out of service in order to perform routine diagnostic
  2971. tests.
  2972. .PP
  2973. A TMN will enable the exclusion of faulty equipment from operation and 
  2974. as a result it may rearrange equipment or re\(hyroute traffic. 
  2975. .PP
  2976. A TMN can enable the entry of a proposed configuration in order to
  2977. automatically analyze the feasibility of that design before implementing
  2978. it.
  2979. .RT
  2980. .sp 1P
  2981. .LP
  2982. 3.2.3.3
  2983.     \fIInstallation functions\fR 
  2984. .sp 9p
  2985. .RT
  2986. .PP
  2987. The TMN can support the installation of equipment which makes up
  2988. the telecommunication network. It covers also the extension or reduction 
  2989. of a system. Some NEs call for the initial exchange of data between themselves 
  2990. and the TMN. An example of another function is the installation of programs 
  2991. into 
  2992. NEs from data base systems within the TMN. In addition, administrative 
  2993. data can be exchanged between NEs and the TMN. 
  2994. .PP
  2995. Acceptance testing programmes can be done under control of, or
  2996. supported by, the TMN.
  2997. .PP
  2998. A detailed list of installation functions for an SPC\(hyexchange is
  2999. provided in Recommendation\ Z.331, \(sc\ 3.3\ [1].
  3000. .bp
  3001. .RT
  3002. .sp 1P
  3003. .LP
  3004. 3.2.4
  3005.     \fIAccounting management\fR 
  3006. .sp 9p
  3007. .RT
  3008. .PP
  3009. Accounting management provides a set of functions which enables the use 
  3010. of the network service to be measured and the costs for such use to be 
  3011. determined. It provides facilities to:
  3012. .RT
  3013. .LP
  3014.     \(em
  3015.     collect accounting records,
  3016. .LP
  3017.     \(em
  3018.     set billing parameters for the usage of services.
  3019. .sp 1P
  3020. .LP
  3021. 3.2.4.1
  3022.     \fIBilling functions\fR 
  3023. .sp 9p
  3024. .RT
  3025. .PP
  3026. An OS within the TMN can collect data from NEs which is used to
  3027. determine charges to customer accounts. This type of function may need
  3028. extremely efficient and redundant data transport capabilities in order to
  3029. maintain records of billing activity. Often the processing must be carried 
  3030. out in near real time for a large number of customers. 
  3031. .RT
  3032. .sp 1P
  3033. .LP
  3034. 3.2.5
  3035.     \fISecurity management\fR 
  3036. .sp 9p
  3037. .RT
  3038. .PP
  3039. (For further study.)
  3040. .RT
  3041. .sp 2P
  3042. .LP
  3043. \fB4\fR     \fBPlanning and design considerations\fR 
  3044. .sp 1P
  3045. .RT
  3046. .PP
  3047. A TMN should be designed such that it has the capability to
  3048. interface with several types of communications paths to ensure that a framework 
  3049. is provided which is flexible enough to allow for the most efficient 
  3050. communications between the NE and the TMN, work stations and the TMN, between 
  3051. elements within the TMN or between TMNs. The basis for choosing the appropriate 
  3052. interfaces however, should be the functions performed by the elements between 
  3053. which the appropriate communications are performed. 
  3054. .PP
  3055. The interface requirements are measured in terms of function
  3056. attributes that are required to provide the most efficient interface. The
  3057. following is a listing of the function attributes. This list is incomplete 
  3058. and will be subject to further study. 
  3059. .RT
  3060. .sp 1P
  3061. .LP
  3062. 4.1
  3063.     \fIFunctions attributes\fR 
  3064. .sp 9p
  3065. .RT
  3066. .LP
  3067.     a)
  3068.     \fIReliability\fR 
  3069. .LP
  3070.     The capability of the interface to ensure that data and
  3071. control is transferred such that integrity and security are maintained.
  3072. .LP
  3073.     b)
  3074.     \fIFrequency\fR 
  3075. .LP
  3076.     How often data is transferred across the interface
  3077. boundary.
  3078. .LP
  3079.     c)
  3080.     \fIQuantity\fR 
  3081. .LP
  3082.      The amount of data that is transferred across the interface during any 
  3083. transaction. 
  3084. .LP
  3085.     d)
  3086.     \fIPriority\fR 
  3087. .LP
  3088.     Indicates precedence to be given to data in case of
  3089. competition for network resources with other functions.
  3090. .LP
  3091.     e)
  3092.     \fIAvailability\fR 
  3093. .LP
  3094.     Determines the use of redundancy in the design of the
  3095. communications channels between interfacing elements.
  3096. .LP
  3097.     f
  3098. )
  3099.     \fIDelay\fR 
  3100. .LP
  3101.     Identifies the amount of buffering that may be tolerable
  3102. between interfacing elements. This also impacts communications channel
  3103. designs.
  3104. .PP
  3105. Annex C to this Recommendation provides a table of possible ranges for 
  3106. these function attributes and provides a definition for each range 
  3107. suggested.
  3108. .sp 1P
  3109. .LP
  3110. 4.2
  3111.     \fIFunctional characteristics\fR 
  3112. .sp 9p
  3113. .RT
  3114. .PP
  3115. Each major type of telecommunications equipment has functional
  3116. characteristic needs that can be used to describe the complexity of the
  3117. interface. There are, however, a basic group of TMN application functions 
  3118. that cross all major types of telecommunications equipment. However, there 
  3119. are also unique TMN application functions that are performed by specific 
  3120. categories of major telecommunications equipment. Alarm surveillance is 
  3121. an example of the 
  3122. former, whereas billing information collection is an example of the latter.
  3123. .bp
  3124. .PP
  3125. Functional characteristics of the elements within a TMN, e.g.,\ OS,
  3126. DCN, MD also describe the complexity of interfaces between these elements. 
  3127. Thus an identification of the functions performed by the elements within 
  3128. a TMN are also important considerations in determining the appropriate 
  3129. interfaces both 
  3130. within the TMN and to the NEs.
  3131. .RT
  3132. .sp 1P
  3133. .LP
  3134. 4.3
  3135.     \fICritical\fR 
  3136. \fIattributes\fR 
  3137. .sp 9p
  3138. .RT
  3139. .PP
  3140. Attribute values for a given function are generally consistent
  3141. across the network elements. When considering a single\ Q interface it is
  3142. important to identify the controlling attribute ranges for the design of the
  3143. interface. If there are conflicting attribute values for different functions 
  3144. in a given network element, more than one interface may be needed. 
  3145. .PP
  3146. Overall TMN attribute values for the interfacing of elements within
  3147. the TMN depend on the type and number of functions performed within these
  3148. elements. In this case the functions are not consistent across TMN elements,
  3149. but are controlled by the individual TMN design of an Administration.
  3150. .RT
  3151. .sp 1P
  3152. .LP
  3153. 4.4
  3154.     \fIProtocol selection\fR 
  3155. .sp 9p
  3156. .RT
  3157. .PP
  3158. In many cases more than one PQ protocol suites will meet the
  3159. requirements for the network element or TMN element under consideration. 
  3160. Care should be taken by the Administration to select the protocol suite 
  3161. that 
  3162. optimizes the relationship between the total cost to implement that protocol
  3163. suite and the data communications channels that carry the information across
  3164. the interface.
  3165. .PP
  3166. The subject of protocol selection methodology will require further
  3167. study in conjunction with other Study Groups.
  3168. .RT
  3169. .sp 1P
  3170. .LP
  3171. 4.5
  3172.     \fICommunications considerations\fR 
  3173. .sp 9p
  3174. .RT
  3175. .PP
  3176. LCN and DCN architectures must be planned and designed to ensure
  3177. that their implementation provides appropriate degrees of availability and
  3178. network delay while minimizing cost. One must consider the selection of
  3179. communications architectures, e.g., star, multipoint, loop, tree. The
  3180. communications channels, e.g., dedicated lines, circuit switched networks 
  3181. and packet networks used in providing the communications paths, also play 
  3182. an 
  3183. important role.
  3184. .RT
  3185. .sp 2P
  3186. .LP
  3187. \fB5\fR     \fBDetailed TMN architectural considerations\fR 
  3188. .sp 1P
  3189. .RT
  3190. .sp 1P
  3191. .LP
  3192. 5.1
  3193.     \fIGeneral\fR 
  3194. .sp 9p
  3195. .RT
  3196. .PP
  3197. The TMN architecture must provide a high degree of flexibility to meet 
  3198. the various topological conditions of the network itself and the 
  3199. organization of the Administrations. Examples of the topological conditions 
  3200. are the physical distribution of the NEs, the number of NEs and the communication 
  3201. volume of the NEs. Examples of the organization are the degree of 
  3202. centralization of personnel and the administrative practices. TMN architecture 
  3203. will be such that the NEs will operate in the same way, independently of 
  3204. the OS architecture. 
  3205. .PP
  3206. The TMN must be carefully designed in order to prevent a single fault from 
  3207. making the transfer of critical management messages impossible. Congestion 
  3208. in the DCN or LCN should not cause blocking or excessive delay of network 
  3209. management messages that are intended to correct the congestion situation or
  3210. restore a faulty system.
  3211. .PP
  3212. As an example of the single fault situation in a critical NE such as a 
  3213. local switch, a separate channel can be provided for \fIemergency action\fR 
  3214.  |  The emergency action function, when provided, requires an independent 
  3215. maintenance capability when the normal OS is inoperative or when the NE 
  3216. has degraded to the point where the normal surveillance functions cannot 
  3217. operate. For these reasons the emergency action OS may be separate from 
  3218. the normal maintenance OS, 
  3219. although they are usually at the same location. OSs and NEs which provide 
  3220. the emergency action function may require at least two physical access 
  3221. channels to the DCN for redundancy. 
  3222. .PP
  3223. Another example is a TMN which is used to determine charges to the
  3224. customers. The OSs and the NEs which are associated with this function 
  3225. require at least two physical DCN communication channels in order to provide 
  3226. sufficient reliability in the collection process by the OSs of charging 
  3227. messages from the NEs. 
  3228. .PP
  3229. The nature of transmission line systems provides the possibility to
  3230. transport a management message in two directions so that, assuming only one
  3231. fault exists at a time, one of the two directions is available.
  3232. .bp
  3233. .RT
  3234. .sp 2P
  3235. .LP
  3236. 5.2
  3237.     \fIOperations system\fR 
  3238. .sp 1P
  3239. .RT
  3240. .sp 1P
  3241. .LP
  3242. 5.2.1
  3243.     \fIFunctional OS configuration\fR 
  3244. .sp 9p
  3245. .RT
  3246. .PP
  3247. There are at least three functional types of OSFs, i.e.\ basic,
  3248. network and service. Basic OSFs perform TMN application functions related to
  3249. NEs located in specific regions. Network OSFs realize the network TMN
  3250. application functions by performing the communication between basic OSFs.
  3251. Service OSFs perform specific TMN application functions for managing an
  3252. individual service. Basic OSFs and network OSFs share the same infrastructure 
  3253. of a telecommunication network. Service OSFs are concerned with service 
  3254. aspects of one or more telecommunication networks. 
  3255. .RT
  3256. .sp 1P
  3257. .LP
  3258. 5.2.2
  3259.     \fIPhysical OS configuration\fR 
  3260. .sp 9p
  3261. .RT
  3262. .PP
  3263. The OS physical architecture must provide the alternatives of
  3264. either centralizing or distributing the general functions, which
  3265. include:
  3266. .RT
  3267. .LP
  3268.     a)
  3269.     support application programs;
  3270. .LP
  3271.     b)
  3272.     data base functions;
  3273. .LP
  3274.     c)
  3275.     user terminal support;
  3276. .LP
  3277.     d)
  3278.     analysis programs;
  3279. .LP
  3280.     e)
  3281.     data formatting and reporting.
  3282. .PP
  3283. The OS functional architecture may be realized on various numbers of OSs, 
  3284. depending on the network size. 
  3285. .PP
  3286. The categorization of TMN function attributes as given in
  3287. Tables\ C\(hy1/M.30 to C\(hy3/M.30 are also important factors in the OS 
  3288. physical 
  3289. architecture. For example, the choice of hardware depends strongly on whether 
  3290. an OS provides real time, near real time or non\(hyreal time service. 
  3291. .PP
  3292. Normally OS functions will be implemented in a set of OSs with a Q\d3\uinterface 
  3293. connected to the DCN. However, this should not preclude a practical realization 
  3294. whereby some of these functions are implemented in an NE or an MD. 
  3295. .PP
  3296. An OS which supports maintenance must provide for two types of data
  3297. communication: spontaneous transmission of messages concerning problems from
  3298. the NE to the OS, and two\(hyway dialogue, when the OS obtains supporting
  3299. information from the NE and sends commands to the NE. In addition, a
  3300. maintenance OS is responsible for assuring the integrity of the maintenance
  3301. data channels through a data communication network.
  3302. .RT
  3303. .sp 2P
  3304. .LP
  3305. 5.3
  3306.     \fITMN data communication considerations\fR 
  3307. .sp 1P
  3308. .RT
  3309. .sp 1P
  3310. .LP
  3311. 5.3.1
  3312.     \fIData communication networks\fR \fIconsiderations\fR 
  3313. .sp 9p
  3314. .RT
  3315. .PP
  3316. A DCN for a TMN should, wherever possible, follow the reference
  3317. model for open systems interconnection for CCITT applications as specified 
  3318. in Recommendation\ X.200\ [2]. 
  3319. .PP
  3320. Within a TMN the necessary physical connection (e.g.\ circuit switched 
  3321. or packet switched) may be offered by communication paths constructed with 
  3322. all kinds of network components, e.g., dedicated lines, public switched 
  3323. data 
  3324. network, ISDN, common channel signalling network, public switched telephone
  3325. network, local area networks, terminal controllers, etc. In the extreme case
  3326. the communication path provides for full connectivity, i.e. each attached
  3327. system can be physically connected to all others.
  3328. .PP
  3329. All connections not using a type\ Q, F or X interface are outside of
  3330. a\ TMN.
  3331. .PP
  3332. A data communications network (DCN) connects NEs with internal
  3333. mediation functions or mediation devices to the OSs and always interfaces at
  3334. the standard Q\d3\ulevel. The use of standard Q\d3\uinterfaces enables 
  3335. maximum flexibility in planning the necessary communications. In general, 
  3336. a DCN does 
  3337. not provide all the data communication functions for a TMN. Therefore, the
  3338. communication between Q\d1\u, Q\d2\uand Q\d3\uinterfaces may require
  3339. communication links, as part of an LCN.
  3340. .PP
  3341. A DCN can be implemented using point\(hyto\(hypoint circuits, a switched
  3342. network or a packet network. The facilities can be dedicated to a DCN or 
  3343. be a shared facility (e.g.\ using CCITT Signalling System No.\ 7 or an 
  3344. existing packet switched network). 
  3345. .bp
  3346. .RT
  3347. .sp 1P
  3348. .LP
  3349. 5.3.2
  3350.     \fILocal communications network\fR \fIconsiderations\fR 
  3351. .sp 9p
  3352. .RT
  3353. .PP
  3354. Within a TMN, the necessary physical connection may be locally
  3355. offered by all kinds of network configurations, e.g., point\(hyto\(hypoint, 
  3356. star, bus or ring. 
  3357. .PP
  3358. A local communication network (LCN) connects NEs to MDs or MDs to MDs and 
  3359. generally interfaces at two standard levels, Q\d1\uand Q\d2\u, within a 
  3360. telecommunication center. However, for practical reasons, an LCN may connect
  3361. remote NEs to local MDs. In some cases, NEs with internal mediation functions 
  3362. may be connected to a DCN through an LCN via a standard Q\d3\uinterface. 
  3363. .RT
  3364. .sp 2P
  3365. .LP
  3366. 5.4
  3367.     \fIMediation\fR 
  3368. .sp 1P
  3369. .RT
  3370. .sp 1P
  3371. .LP
  3372. 5.4.1
  3373.     \fIMediation considerations\fR 
  3374. .sp 9p
  3375. .RT
  3376. .PP
  3377. Mediation is a process within a TMN which acts on information
  3378. passing between network elements (NE) and operations systems (OS) via a data
  3379. communication network. Mediation devices use standard interfaces and can be
  3380. shared by several NE(s) and/or OS(s).
  3381. .PP
  3382. \fINote\fR \ \(em\ Mediation devices accommodate different designs of NEs 
  3383. when acting on information passing from these NEs to OSs by appropriate 
  3384. implementation of communication functions. The mediation function may be
  3385. implemented in stand alone devices or combined with other unrelated functions 
  3386. (e.g.\ with a local processor or with a switching exchange). Mediation 
  3387. functions can be implemented as a hierarchy of cascaded devices using standard 
  3388. interfaces. Examples of the mediation function are concentration, protocol
  3389. conversion, collection/control and processing. The mediation function may be
  3390. absent in some implementations.
  3391. .PP
  3392. The cascading of mediation devices and various interconnection
  3393. structures between MDs on one hand and MDs and NEs on the other hand provides 
  3394. for great flexibility in the TMN. Some options are shown in Figure\ 8/M.30. 
  3395. It enables cost effective implementations of the connection of NEs of different 
  3396. complexity (e.g.\ switching equipment and transmission multiplex equipment) 
  3397. to the same TMN. In addition, it gives the capability for future design 
  3398. of new 
  3399. equipment to support a greater level of processing within individual NEs,
  3400. without the need to redesign an existing TMN.
  3401. .PP
  3402. It may be possible to recognize a mediation type process in some
  3403. network elements similar to the one described above. For the purpose of this
  3404. Recommendation, it is convenient to regard the function of mediation as 
  3405. being wholly contained within the TMN. However, this does not preclude 
  3406. practical 
  3407. realizations where some or all of the mediation functions are implemented
  3408. within the network element, which must still interface to the TMN via a
  3409. standardized Q interface. The choice of any interface which may be required 
  3410. for a network element is left to the discretion of the Administrations. 
  3411. .RT
  3412. .sp 1P
  3413. .LP
  3414. 5.4.2
  3415.     \fIProcess of mediation\fR 
  3416. .sp 9p
  3417. .RT
  3418. .PP
  3419. Mediation is a process that routes and/or acts on information
  3420. passing between NEs and OSs. The processes that can form mediation can be
  3421. classified into the following five general process categories:
  3422. .RT
  3423. .LP
  3424.     1)
  3425.     communication control;
  3426. .LP
  3427.     2)
  3428.     protocol conversion and data handling;
  3429. .LP
  3430.     3)
  3431.     transfer of primitive functions;
  3432. .LP
  3433.     4)
  3434.     decision making processes;
  3435. .LP
  3436.     5)
  3437.     data storage.
  3438. .PP
  3439. A number of more specific processes can be identified within each of these 
  3440. general process categories, some examples of which are given below. 
  3441. Mediation may consist of one or more of these specific processes:
  3442. .LP
  3443.     a)
  3444.     communications control:
  3445. .LP
  3446.     \(em
  3447.     polling,
  3448. .LP
  3449.     \(em
  3450.     addressing,
  3451. .LP
  3452.     \(em
  3453.     communications networking,
  3454. .LP
  3455.     \(em
  3456.     ensuring integrity of data flows;
  3457. .LP
  3458.     b)
  3459.     protocol conversion and data handling:
  3460. .LP
  3461.     \(em
  3462.     protocol conversion at either lower or upper OSI
  3463. levels,
  3464. .LP
  3465.     \(em
  3466.     concentration of data,
  3467. .LP
  3468.     \(em
  3469.     compression or reduction of data,
  3470. .LP
  3471.     \(em
  3472.     collection of data,
  3473. .LP
  3474.     \(em
  3475.     data formatting,
  3476. .LP
  3477.     \(em
  3478.     data translation;
  3479. .bp
  3480. .LP
  3481.     c)
  3482.     tranfer of primitive functions:
  3483. .LP
  3484.     \(em
  3485.     command/response statement,
  3486. .LP
  3487.     \(em
  3488.     alarm statements,
  3489. .LP
  3490.     \(em
  3491.     alarm forwarding,
  3492. .LP
  3493.     \(em
  3494.     test results/data,
  3495. .LP
  3496.     \(em
  3497.     operational measurement data,
  3498. .LP
  3499.     \(em
  3500.     upload of status report,
  3501. .LP
  3502.     \(em
  3503.     local alarming;
  3504. .LP
  3505.     d)
  3506.     decision making processes:
  3507. .LP
  3508.     \(em
  3509.     work station access,
  3510. .LP
  3511.     \(em
  3512.     thresholding,
  3513. .LP
  3514.     \(em
  3515.     data communications back\(hyup,
  3516. .LP
  3517.     \(em
  3518.     routing/re\(hyrouting of data,
  3519. .LP
  3520.     \(em
  3521.     security (e.g., log\(hyin procedures),
  3522. .LP
  3523.     \(em
  3524.     fault sectionalization tests,
  3525. .LP
  3526.     \(em
  3527.     circuit selection and access for tests,
  3528. .LP
  3529.     \(em
  3530.     circuit test analysis;
  3531. .LP
  3532.     e)
  3533.     data storage:
  3534. .LP
  3535.     \(em
  3536.     data\(hybase storage,
  3537. .LP
  3538.     \(em
  3539.     network configuration,
  3540. .LP
  3541.     \(em
  3542.     equipment identification,
  3543. .LP
  3544.     \(em
  3545.     memory back\(hyup.
  3546. .PP
  3547. Certain mediation processes may be carried out autonomously.
  3548. .PP
  3549. The mediation function of the TMN permits a flexible design of the
  3550. architecture NE to OS. Different architectural designs for operations,
  3551. administration and maintenance communications can be accommodated in the 
  3552. same TMN by appropriate implementation of the hierarchical configuration 
  3553. of 
  3554. mediation. By these means, NEs of different complexity (e.g. switching 
  3555. exchange or multiplex equipment) can connect into the same TMN. 
  3556. .RT
  3557. .sp 1P
  3558. .LP
  3559. 5.4.3
  3560.     \fIImplementation of mediation processes\fR 
  3561. .sp 9p
  3562. .RT
  3563. .PP
  3564. Mediation processes can be implemented as stand\(hyalone equipment or as 
  3565. part of an NE. In either case the mediation function remains part of the 
  3566. TMN.
  3567. .PP
  3568. In the stand\(hyalone case the interfaces towards both NEs and OSs are
  3569. one or more of the standard operations interfaces (Q\d1\u, Q\d2\uand Q\d3\u).
  3570. Where
  3571. mediation is part of an NE only, the interfaces towards the OSs are specified 
  3572. as one or more of the standard operations interfaces (Q\d2\uand Q\d3\u). 
  3573. Mediation that is part of an NE (e.g. as part of a switching exchange) 
  3574. may also act as mediation for other NEs. In this case standard operations 
  3575. interfaces 
  3576. (Q\d1\uand Q\d2\u) to these other NEs are required.
  3577. .PP
  3578. Also, the mediation functions within an NE which carries out the
  3579. mediation function for other NEs is regarded as being a part of the TMN.
  3580. .RT
  3581. .sp 1P
  3582. .LP
  3583. 5.5
  3584.     \fINetwork element\fR \fIconsiderations\fR 
  3585. .sp 9p
  3586. .RT
  3587. .PP
  3588. In the TMN reference model, a network element performs the network element 
  3589. function (NEF), and may in addition perform one or more MFs. 
  3590. .PP
  3591. The study of various application examples leads to the desirability to 
  3592. distinguish between the following functions contained in an NEF: 
  3593. .RT
  3594. .LP
  3595.     \(em
  3596.     The Maintenance entity function (MEF) is involved in the
  3597. telecommunication process. Typical MEFs are switching and transmission. A
  3598. maintenance entity (ME) can contain one or more MEFs.
  3599. .LP
  3600.     \(em
  3601.      The support entity function (SEF) is not directly involved in the telecommunication 
  3602. process. Typical SEFs are fault localization, billing, protection switching. 
  3603. A support entity (SE) can contain one or more SEFs. 
  3604. .LP
  3605.     \(em
  3606.     The Q\(hyadapter function (QAF) is used to connect to TMN
  3607. those MEs and SEs which do not provide standard TMN interfaces. Typical QAFs
  3608. are interface conversions. A Q\(hyadapter (QA) can contain one or more 
  3609. QAFs and may also contain MFs. 
  3610. .bp
  3611. .PP
  3612. This approach to definitions of the parts of an NE which perform operations 
  3613. functions implies the following relationships: 
  3614. .LP
  3615.     \(em
  3616.     an NE contains MEs or SEs or both MEs and SEs;
  3617. .LP
  3618.     \(em
  3619.     an NE may or may not contain a QA.
  3620. .PP
  3621. Note that the various parts of an NE are not geographically
  3622. constrained to one physical location. For example, the parts may be distributed 
  3623. along a transmission system. 
  3624. .PP
  3625. Figure 9/M.30 shows the NE reference model outside the TMN with
  3626. related physical implementations. The m\(hyreference point separates the
  3627. maintenance entity function (MEF), the support entity function (SEF), and 
  3628. the Q\(hyadapter function (QAF). 
  3629. .PP
  3630. Figure 10/M.30 shows different types of Q\(hyadapters connected to MEs
  3631. and SEs. The Q\(hyadapters are not required if MEs or SEs are supplied with
  3632. Q\(hyinterfaces. The M\(hyinterface can be of parallel, star or bus\(hytype.
  3633. .PP
  3634. Examples of network elements are shown in Annex\ A.
  3635. .RT
  3636. .LP
  3637. .rs
  3638. .sp 22P
  3639. .ad r
  3640. \fBFigure 9/M.30, p. 17\fR 
  3641. .sp 1P
  3642. .RT
  3643. .ad b
  3644. .RT
  3645. .sp 1P
  3646. .LP
  3647. 5.6
  3648.     \fIWork stations\fR 
  3649. .sp 9p
  3650. .RT
  3651. .PP
  3652. In Figure 2/M.30 and 3/M.30, the work station reference points and interfaces 
  3653. are shown at a number of locations. An Administration may choose to implement 
  3654. a work station at only some of these locations. 
  3655. .PP
  3656. The TMN work stations and their interfaces are subjects for further
  3657. study.
  3658. .RT
  3659. .sp 1P
  3660. .LP
  3661. 5.7
  3662.     \fITMN standard interfaces\fR 
  3663. .sp 9p
  3664. .RT
  3665. .PP
  3666. TMN standard interfaces provide for the interconnection of NEs,
  3667. OSs, MDs and WSs through the DCN or LCN. The purpose of an interface
  3668. specification is to assure compatibility of devices interconnected to
  3669. accomplish a given TMN application function, independent of the type of 
  3670. device or of the supplier. This requires compatible communication protocols 
  3671. and a 
  3672. compatible data representation method for the messages, including compatible
  3673. generic message definitions for TMN application functions. A minimum set of
  3674. protocol suites, to be applied to TMN standard interfaces, should be determined 
  3675. according to the protocol selection method described in\ \(sc\ 4.4. 
  3676. .bp
  3677. .RT
  3678. .LP
  3679. .rs
  3680. .sp 47P
  3681. .ad r
  3682. \fBFigure 9/M.30, p.\fR 
  3683. .sp 1P
  3684. .RT
  3685. .ad b
  3686. .RT
  3687. .LP
  3688. .bp
  3689. .PP
  3690. Consideration should be given to compatibility with the most
  3691. efficient
  3692. data transport facilities available to reach individual network elements
  3693. (e.g.\ leased circuits, circuit switched connections, X.25 packet switched
  3694. connections, CCITT Signalling System No.\ 7, embedded operations channels and
  3695. ISDN access network D\(hy\ and\ B\(hychannels).
  3696. .PP
  3697. It is recognized that NEs, OSs, DCNs, LCNs, MDs and WSs may have other 
  3698. interfaces in addition to the Q, F, G and X interfaces defined in this 
  3699. Recommendation. It is also recognized that this equipment may have other
  3700. functionality in addition to that associated with information sent or received 
  3701. via Q, F, G and X interfaces. These additional interfaces and related 
  3702. functionality are outside the TMN.
  3703. .RT
  3704. .sp 1P
  3705. .LP
  3706. 5.7.1
  3707.     \fIQ\fR
  3708. .sp 9p
  3709. .RT
  3710. .EF '%    \fI1\ and\''
  3711. .OF '''\fI1\ and\    %'
  3712. .EF '%    \fI2\ interfaces''
  3713. .OF '''\fI2\ interfaces    %'
  3714. .PP
  3715. The PQ\dL\\dC\\dN\ufunction attributes required at the Q\d1\u/Q\d2\uinterfaces 
  3716. are strongly dependent on the mediation functions needed, as well as the 
  3717. mediation function partitioning between cascaded MDs. Since the purpose 
  3718. of putting MDs between OSs and NEs is to make flexible implementation possible, 
  3719. mediation function partitioning should not be restricted to only one case.
  3720. Therefore, one minimum set of protocol suites should be selected to be 
  3721. applied to both Q\d1\uand Q\d2\uinterfaces instead of selecting a different 
  3722. set for 
  3723. each of them. The choice of individual protocol suites from the recommended
  3724. PQ\dL\\dC\\dN\ufamily should be left to the Administrations.
  3725. .PP
  3726. The protocol suites to be applied to the Q\d1\uand Q\d2\uinterfaces
  3727. need not implement all layers of the OSI model. Details of the Q\d1\uand 
  3728. Q\d2\uinterface specification and the PQ\dL\\dC\\dN\ufamily of protocol 
  3729. suites are 
  3730. given in Recommendation\ G.771\ [3].
  3731. .RT
  3732. .sp 1P
  3733. .LP
  3734. 5.7.2
  3735.     \fIQ\fR
  3736. .sp 9p
  3737. .RT
  3738. .EF '%    \fI3\ interface''
  3739. .OF '''\fI3\ interface    %'
  3740. .PP
  3741. For the PQ\dD\u\dC\\dN\uprotocols, it is recommended that each set   of
  3742. TMN application functions with similar protocol needs be supported with 
  3743. unique protocol selections for layers\ 4 to\ 7 as defined by the OSI Reference 
  3744. Model 
  3745. (Recommendation\ X.200\ [2]). The anulling of service options of individual
  3746. layers above layer\ 3, and even entire layers above layer\ 3, may be necessary
  3747. for justifiable economic reasons. In addition, protocol options will likely 
  3748. be required for the PQ\dD\u\dC\\dN\uprotocols for layers\ 1,\ 2 and\ 3 
  3749. in order to 
  3750. permit the use of the most efficient data transport.
  3751. .PP
  3752. Details of the Q\d3\uinterfaces and the PQ\dD\u\dC\\dN\uprotocols are given 
  3753. in Recommendation\ Q.513\ [4]. 
  3754. .RT
  3755. .sp 2P
  3756. .LP
  3757. 5.7.3
  3758.     \fIF interface\fR  | (under study)
  3759. .sp 1P
  3760. .RT
  3761. .sp 1P
  3762. .LP
  3763. 5.7.4
  3764.     \fIX interface\fR  | (under study)
  3765. .sp 9p
  3766. .RT
  3767. .PP
  3768. Interconnection to other TMNs.
  3769. .RT
  3770. .sp 2P
  3771. .LP
  3772. \fB6\fR     \fBUser interface\fR (under study)
  3773. .sp 1P
  3774. .RT
  3775. .PP
  3776. This section will provide information and recommendations about the possible 
  3777. location and type of user work stations to be provided with a TMN. It will 
  3778. discuss work station back\(hyup considerations when parts of the TMN have 
  3779. failed.
  3780. .RT
  3781. .sp 2P
  3782. .LP
  3783. \fB7\fR     \fBTMN maintenance considerations\fR (under study)
  3784. .sp 1P
  3785. .RT
  3786. .PP
  3787. This section will provide information and recommendations about the considerations 
  3788. associated with the maintenance of the TMN itself. 
  3789. .RT
  3790. .LP
  3791. .rs
  3792. .sp 2P
  3793. .ad r
  3794. Blanc
  3795. .ad b
  3796. .RT
  3797. .LP
  3798. .bp
  3799.